System and method for managing environmental conditions for an autonomous vehicle

ABSTRACT

Systems and methods for managing environmental conditions for an autonomous vehicle are disclosed. In one aspect, an autonomous vehicle includes a perception sensor configured to generate perception data indicative of a condition of the environment, a network communication transceiver configured to communicate with an oversight system and an external weather condition source, a non-transitory computer readable medium, and a processor. The processor is configured to: receive the perception data from the at least one perception sensor, receive an indication of current weather conditions from the external weather condition source, determine a current environmental condition severity level from a plurality of severity levels based on the perception data and the indication of current weather conditions, modify one or more driving parameters that that govern a range of actions that can be autonomously executed by the autonomous vehicle, and navigate the autonomous vehicle based on the modified driving parameters.

CROSS-REFERENCE TO RELATED APPLICATION(S)

This application is a continuation of U.S. Non-Provisional Pat. Application No. 18/050,966, filed Oct. 28, 2022, which claims the benefit of priority from U.S. Provisional Pat. Application No. 63/273,868, filed on Oct. 29, 2021. Any and all applications for which a foreign or domestic priority claim is identified in the Application Data Sheet as filed with the present application are hereby incorporated by reference under 37 CFR 1.57.

BACKGROUND Technical Field

The present disclosure relates generally to autonomous vehicles. More particularly, the present disclosure is related to operating an autonomous vehicle (AV) appropriately on public roads, highways, and locations with other vehicles or pedestrians.

Description of the Related Technology

One aim of autonomous vehicle technologies is to provide vehicles that can safely navigate towards a destination with limited or no driver assistance. The safe navigation of an autonomous vehicle (AV) from one point to another may include the ability to signal other vehicles, navigating around other vehicles in shoulders or emergency lanes, changing lanes, biasing appropriately in a lane, and navigate all portions or types of highway lanes. Autonomous vehicle technologies may enable an AV to operate without requiring extensive learning or training by surrounding drivers, by ensuring that the AV can operate safely, in a way that is evident, logical, or familiar to surrounding drivers and pedestrians.

SUMMARY OF SOME INVENTIVE ASPECTS

Systems and methods are described herein that allow an autonomous vehicle (AV) to navigate from a first point to a second point without a human driver present in the AV and to comply with instructions for safe and lawful operation.

In one aspect, there is provided an autonomous vehicle configured to drive on a roadway, comprising: at least one perception sensor configured to generate perception data indicative of at least one other vehicle on the roadway; a processor; and a non-transitory computer readable medium having stored thereon instructions that, when executed by the processor, cause the processor to: determine that the other vehicle is violating one or more rules of the roadway based on the perception data, tag the other vehicle as a non-compliant driver, and modify control of the autonomous vehicle in response to tagging the other vehicle as a non-compliant driver.

In some embodiments, the processor is further configured to: determine that the other vehicle is in a lane adjacent to that of the autonomous vehicle; determine that a portion of the other vehicle has crossed a lane boundary on a side closest to the autonomous vehicle; in response to determining that the other vehicle is in the lane adjacent to that of the autonomous vehicle and that the portion of the other vehicle has crossed the lane boundary on the side closest to the autonomous vehicle, tag the other vehicle as a lane crossing non-compliant driver; and monitor the lane crossing non-compliant driver for a potential cut into the autonomous vehicle’s lane.

In some embodiments, the processor is further configured to: determine that the other vehicle is an erratic non-compliant driver in response to determining that the other vehicle has broken traffic laws in one or more of the following ways: the other vehicle is driving the wrong way, opposite to a flow of traffic, the other vehicle is driving outside of drivable lanes or on a gore area, and/or the other vehicle has cut across multiple lanes of traffic without utilizing a turn signal.

In some embodiments, the processor is further configured to maintain the non-compliant driver tag on the other vehicle for a predetermined length of time.

In some embodiments, the processor is further configured to cause the autonomous vehicle to minimize an amount of time that the autonomous vehicle drives and/or remains parallel to the other vehicle tagged as the non-compliant driver.

In some embodiments, the processor is further configured to: determine that the other vehicle is a speeding non-compliant driver in response to the other vehicle moving at a predetermined speed above a speed limit; and in response to determining that the other vehicle is a speeding non-compliant driver, cause the autonomous vehicle to avoid lane changing into a lane of the other vehicle until the other vehicle has passed the autonomous vehicle.

In some embodiments, the processor is further configured to: determine that the other vehicle is an oscillating non-compliant driver in response to detecting that the other vehicle is swerving between both of its lane lines; and in response to determining that the other vehicle is an oscillating non-compliant driver, cause the autonomous vehicle to avoid driving in a lane adjacent to the other vehicle.

In some embodiments, the processor is further configured to: determine that the other vehicle is an intersection non-compliant driver in response to detecting that the other vehicle has proceeded into an intersection when the other vehicle does not have a right-of-way; and in response to determining that the other vehicle is an intersection non-compliant driver, cause the autonomous vehicle to yield a right-of-way to the other driver.

In some embodiments, the processor is further configured to cause the autonomous vehicle to avoid changing lanes towards the tagged non-compliant driver unless changing lanes is required to continue on a route of the autonomous vehicle.

Another aspect includes a non-transitory computer-readable medium having stored thereon instructions which, when executed by a processor, cause the processor to: determine that another vehicle is violating one or more rules of a roadway based on perception data received from one or more sensors of an autonomous vehicle; tag the other vehicle as a non-compliant driver; and modify control of the autonomous vehicle in response to tagging the other vehicle as a non-compliant driver.

In some embodiments, the instructions further cause the processor to: determine whether there is a potential for an accident between the autonomous vehicle and the other vehicle; and in response to determining that there is the potential for an accident between the autonomous vehicle and the other vehicle, determine an evasive maneuver by the autonomous vehicle to avoid or minimize any damage to the autonomous vehicle and other entities on or near the roadway.

In some embodiments, the instructions further cause the processor to: determine whether the potential for the accident is an emergency scenario in which the accident is imminent; and cause the autonomous vehicle to execute the evasive maneuver in response to determining that the potential for the accident is the emergency scenario.

In some embodiments, the instructions further cause the processor to: calculate that a critical distance between the autonomous vehicle and the other vehicle cannot be maintained even using a threshold deceleration; and determine that the accident is imminent in response to calculating that the critical distance between the autonomous vehicle and the other vehicle cannot be maintained even using the threshold deceleration.

In some embodiments, the instructions further cause the processor to cause the autonomous vehicle to stay within its lane when executing an evasive maneuver unless evasive braking alone is not enough to prevent a collision.

In some embodiments, the instructions further cause the processor to: determine that a previously obstructed vehicle has been revealed due to the other vehicle being removed as a source of obstruction, and in response to determining that the previously obstructed vehicle is now unobstructed, cause the autonomous vehicle to brake up to a maximum amount of braking within safety limits to maintain a critical distance between the autonomous vehicle and the previously obstructed vehicle.

In some embodiments, the instructions further cause the processor to: determine that the other vehicle, in front of and in a same lane as the autonomous vehicle, has suddenly applied its brakes with a deceleration of greater than a predetermined amount of deceleration; and in response to determining that that the other vehicle has suddenly applied its brakes, cause the autonomous vehicle to brake up to a maximum amount of braking within safety limits.

Another aspect is a method comprising: determining that another vehicle is violating one or more rules of a roadway based on perception data received from one or more sensors of an autonomous vehicle; tagging the other vehicle as a non-compliant driver; and modifying control of the autonomous vehicle in response to tagging the other vehicle as a non-compliant driver.

In some embodiments, the method further comprises: detecting that the autonomous vehicle has been involved in an accident; determining a severity of the accident; and based on detecting that the autonomous vehicle has been involved in an accident and the determined severity, determine a course of action to minimize any further damage to the autonomous vehicle and/or any other entities on or near the roadway.

In some embodiments, detecting that the autonomous vehicle has been involved in an accident is based on information received from one or more inertial sensors, one or more cameras, and/or one or more lidars of the autonomous vehicle.

In some embodiments, the method further comprises: determining that the severity of the accident is severe in response to a detected deceleration being greater than a threshold deceleration and/or determining that an object the autonomous vehicle has collided with is a pedestrian, a cyclist, a motorcycle, and/or another vulnerable road user.

Another aspect is an autonomous vehicle configured to drive on a roadway, comprising: at least one perception sensor configured to detect roadway conditions data including roadway grade data; a processor; and a non-transitory computer readable medium configured to store mapped data, the mapped data having roadway grade data, and to store instructions that, when executed by the processor, cause the processor to: receive the detected roadway conditions data including roadway grade data from the at least one perception sensor, retrieve the mapped data having roadway grade data from the non-transitory computer readable medium, determine that the roadway has a grade based on the detected roadway grade data and the retrieved roadway grade data, in response to determining that the roadway has a grade, determine that the grade of the roadway is greater than or equal to a predetermined high grade value and less than a predetermined grade limit; and in response to determining that the grade of the roadway is greater than or equal to the predetermined high grade value and less than the predetermined grade limit, operate the autonomous vehicle to change its lane to a right-most lane.

In some embodiments, the predetermined grade limit is 7%.

In some embodiments, the predetermined grade limit is 9%.

In some embodiments, the predetermined high grade value is 5%.

In some embodiments, the predetermined high grade value is 7%.

In some embodiments, in response to determining that the grade of the roadway is greater than or equal to the predetermined grade limit, the processor is further configured to take a minimal risk condition (MRC) maneuver to stop the autonomous vehicle.

In some embodiments, the processor is further configured to stop the autonomous vehicle at a shoulder.

In some embodiments, in response to determining that the grade of the roadway is less than the predetermined high grade value, the processor is further configured to follow a speed limit indicated by a road grade traffic sign detected by the at least one perception sensor or retrieved from the mapped data.

Another aspect is a method comprising: receiving detected roadway conditions data including roadway grade data from at least one perception sensor of an autonomous vehicle; retrieving mapped data having roadway grade data from a non-transitory computer readable medium of the autonomous vehicle; determining that the roadway has a grade based on the detected roadway grade data and the retrieved roadway grade data; in response to determining that the roadway has a grade, determining that the grade of the roadway is greater than or equal to a predetermined high grade value and less than a predetermined grade limit; and in response to determining that the grade of the roadway is greater than or equal to the predetermined high grade value and less than the predetermined grade limit, operating the autonomous vehicle to change its lane to a right-most lane.

In some embodiments, the method further comprises: determining there is a discrepancy between the detected roadway grade data and the retrieved roadway grade data; and in response to determining there is a discrepancy between the detected roadway grade data and the retrieved roadway grade data, taking the detected roadway grade data as higher priority over the retrieved roadway grade data.

In some embodiments, the autonomous vehicle is an autonomous truck.

In some embodiments, the detected roadway grade data includes a grade value, a grade sign including a positive sign or a negative sign, and a grade length.

In some embodiments, when the grade sign is determined to be negative, further comprising operating the autonomous vehicle to check brake.

In some embodiments, when the grade sign is determined to be negative, further comprising operating the autonomous vehicle to slow it down to a predetermined speed limit.

In some embodiments, when the grade sign is determined to be negative, further comprising operating the autonomous vehicle to change to a lower gear to slow down.

In some embodiments, when the grade sign is determined to be negative, further comprising operating the autonomous vehicle to change to its lowest gear to slow down.

In some embodiments, when the grade sign is determined to be negative, further comprising: determining that the roadway has an obstacle based on the roadway conditions data from the at least one perception sensor of the autonomous vehicle; and in response to determining that the roadway has an obstacle, operating the autonomous vehicle to engage a foundation brake and change to a lower gear to stop the autonomous vehicle.

In some embodiments, when the grade sign is determined to be negative, further comprising: determining that the roadway has a truck turnout based on the roadway conditions data from the at least one perception sensor of the autonomous vehicle and the retrieved mapped data; and in response to determining that the roadway has a truck turnout, operating the autonomous vehicle to change lane and move into the truck turnout.

In some embodiments, when the grade sign is determined to be positive, further comprising increasing a throttle of the autonomous vehicle.

Another aspect is a non-transitory computer-readable medium having stored thereon mapped data including roadway grade data and instructions which, when executed by a processor, cause the processor to: receive detected roadway conditions data including roadway grade data from at least one perception sensor of an autonomous vehicle; retrieve the mapped data having roadway grade data from the non-transitory computer-readable medium; determine that the roadway has a grade based on the detected roadway grade data and the retrieved roadway grade data; in response to determining that the roadway has a grade, determine that the grade of the roadway is greater than or equal to a predetermined high grade value and less than a predetermined grade limit; and in response to determining that the grade of the roadway is greater than or equal to the predetermined high grade value and less than the predetermined grade limit, operate the autonomous vehicle to change its lane to a right-most lane.

Another aspect is an autonomous vehicle comprising: at least one perception sensor configured to generate perception data indicative of a condition of the environment; a network communication transceiver configured to communicate with an oversight system and receive information from an external weather condition source; a non-transitory computer readable medium; and a processor configured to: receive the perception data from the at least one perception sensor, receive an indication of current weather conditions from the external weather condition source, determine a current environmental condition severity level from a plurality of severity levels based on the perception data and the indication of current weather conditions, modify one or more driving parameters that govern a range of actions that can be autonomously executed by the autonomous vehicle, and navigate the autonomous vehicle based on the modified one or more driving parameters.

In some embodiments, the processor is further configured to: determine a current environmental condition severity level for each of a plurality of different environmental conditions.

In some embodiments, the plurality of different environmental conditions includes two or more of: road traction, stability, or visibility.

In some embodiments, the processor is further configured to: determine that at least two of the plurality of different environmental conditions has a severity level other than normal, wherein modifying the one or more driving parameters is further based on the determination that at least two of the plurality of different environmental conditions have a severity level other than normal.

In some embodiments, the plurality of severity levels comprises at least two of: normal, degraded, cautionary, and critical.

In some embodiments, the processor is further configured to: determine that the current environmental condition is critical, in response to determining that the current environmental condition is critical, cause the autonomous vehicle to execute a minimal risk condition (MRC) maneuver.

In some embodiments, the MRC maneuver comprises pulling the autonomous vehicle over to a safe zone of a roadway.

In some embodiments, the processor is further configured to: determine that the autonomous vehicle is operating out of an operational design domain (ODD) of the autonomous vehicle, in response to determining that the autonomous vehicle is operating out of the ODD, determining that the current environmental condition severity level is critical, and in response to determining that the current environmental condition is critical, cause the autonomous vehicle to execute a first minimum risk condition (MRC) maneuver.

In some embodiments, the processor is further configured to: determine that the autonomous vehicle has been attempting the first MRC for longer than a predetermined period of time without success, and in response to determining that the autonomous vehicle has been attempting the first MRC for longer than a predetermined period of time without success, cause the autonomous vehicle to execute a second MRC maneuver.

In some embodiments, the processor is further configured to: determine that the current environmental condition severity level is degraded, and in response to determining that the current environmental condition severity level is degraded, modify the one or more driving parameters to instruct the autonomous vehicle to change lanes to the right-most lane based on determining that it is safe to perform lane changes.

In some embodiments, the processor is further configured to: determine that the current environmental condition severity level is cautionary, and in response to determining that the current environmental condition severity level is cautionary, modify the one or more driving parameters to instruct the autonomous vehicle to avoid all lane changes, except for lane changes that are required for safety or lane changes required to continue the current mission.

Another aspect is a non-transitory computer-readable medium having stored thereon instructions which, when executed by a processor, cause the processor to: receive perception data from at least one perception sensor of an autonomous vehicle; receive an indication of current weather conditions from an external weather condition source; determine a current environmental condition severity level from a plurality of severity levels based on the perception data and the indication of current weather conditions; modify one or more driving parameters that govern a range of actions that can be autonomously executed by the autonomous vehicle; and navigate the autonomous vehicle based on the modified one or more driving parameters.

In some embodiments, the instructions further cause the processor to: determine a road traction coefficient based on the perception data; and determine that the current environmental condition severity level is degraded in response to the road traction coefficient being less than a threshold value.

In some embodiments, the instructions further cause the processor to: in response to determining that the current environmental condition severity level is degraded: reduce a speed of the autonomous vehicle, perform lane changes with critical intent, apply a maximum available deceleration rate or less to decelerate, if safe to do so, lane change to a right-most lane, and/or maintain a preference for the right-most lane.

In some embodiments, the instructions further cause the processor to: determine that the autonomous vehicle has slowed down to a level below a normal speed but still greater than a threshold speed; and determine that the current environmental condition severity level is degraded in response to determining that the autonomous vehicle has slowed down to the level below the normal speed but still greater than the threshold speed.

In some embodiments, the instructions further cause the processor to: determine a road traction coefficient based on the perception data; determine that the autonomous vehicle has modified its behavior when the road traction coefficient is less than a threshold value; and determine that the current environmental condition severity level is degraded in response to determining that the autonomous vehicle has modified its behavior when the road traction coefficient is less than the threshold value.

Another aspect is a method comprising: receiving perception data from at least one perception sensor of an autonomous vehicle; receiving an indication of current weather conditions from an external weather condition source; selecting a current environmental condition severity level from a plurality of severity levels based on the perception data and the indication of current weather conditions; modifying one or more driving parameters that govern a range of actions that can be autonomously executed by the autonomous vehicle; and navigating the autonomous vehicle based on the modified one or more driving parameters.

In some embodiments, the method of Claim 57, further comprises: estimating a visibility range based on the perception data; determining that the current environmental condition is degraded in response to the visibility range being less than a threshold value.

In some embodiments, the method further comprises: determining that the autonomous vehicle will enter a fog area based on the perception data and the indication of current weather conditions; and activating low beams of the autonomous vehicle in response to determining that the autonomous vehicle will enter the fog area.

In some embodiments, the method further comprises: estimating a level of water based on road crown visibility from the perception data; and slowing down a speed of the autonomous vehicle in response to the level of water being greater than a threshold level.

Another aspect is an autonomous vehicle configured to travel on a roadway, comprising: a trailer; at least one perception sensor configured to generate perception data indicative of: i) one or more parameters of the roadway and ii) a movement of the autonomous vehicle; a processor; and a non-transitory computer readable medium having stored thereon instructions that, when executed by the processor, cause the processor to: estimate a grade of the roadway based on the perception data indicative of the one or more parameters of the roadway, provide a first control input to the autonomous vehicle based on the grade of the roadway, determine a response of the autonomous vehicle to the first control input based on the perception data indicative of the movement of the autonomous vehicle, estimate a trailer load of the trailer based on the response of the autonomous vehicle to the first control input, and provide a second control input to the autonomous vehicle based on the grade of the roadway and the trailer load.

In some embodiments, the first control input comprises a throttle input and/or a brake input.

In some embodiments, the processor is further configured to: determine a wheel torque for one or more wheels of the autonomous vehicle, and estimate a mass of the trailer based on the determined wheel torque, wherein the second control input is further based at least in part on the mass of the trailer.

In some embodiments, the processor is further configured to estimate a force to move the trailer based on the wheel torque, wherein the second control input includes a throttle control and a brake control determined based on the force to move the trailer.

In some embodiments, the processor is further configured to determine a road curvature in front of the autonomous vehicle with a distance greater than a natural deceleration distance based on the perception data indicative of the one or more parameters of the roadway, wherein the second control input is further based on the road curvature.

In some embodiments, the processor is further configured to limit a lateral acceleration of the autonomous vehicle in curves based on a distance to reduce a speed of the autonomous vehicle to limit a lateral acceleration taking into account braking capabilities of the autonomous vehicle.

In some embodiments, the processor is further configured to reduce a speed of the autonomous vehicle to limit a lateral acceleration based on a maximum curvature of the road curvature.

In some embodiments, the second control input includes a throttle control, and wherein the processor is further configured to dynamically adjust the throttle control based on the grade of the roadway and the trailer load to provide a longitudinal control robustness for the throttle control.

In some embodiments, the second control input includes a brake control, and wherein the processor is further configured to dynamically adjust the brake control to compensate for the grade of the roadway and the trailer load to provide a longitudinal control robustness for the brake control.

In some embodiments, the second control input includes a steering control, and wherein the processor is further configured to dynamically adjust the steering control to compensate for side-wind effects and a super elevation rate due to the trailer load to a provide longitudinal control robustness for the steering control.

In some embodiments, the processor is further configured to limit a lateral acceleration to a predetermined acceleration and a predetermined jerk value to maintain a stability of the autonomous vehicle when turning or driving on curved roads taking into account a super elevation rate, and wherein the processor is further configured to limit lateral dynamics for lateral maneuvers of the autonomous vehicle depending on trailer inertia and stability criteria.

Another aspect is a non-transitory computer-readable medium having stored thereon instructions which, when executed by a processor, cause the processor to: estimate a grade of a roadway based on perception data indicative of one or more parameters of the roadway received from one or more perception sensors of an autonomous vehicle; provide a first control input to the autonomous vehicle based on the grade of the roadway; determine a response of the autonomous vehicle to the first control input based on perception data indicative of a movement of the autonomous vehicle received from the one or more perception sensors; estimate a trailer load of the trailer based on the response of the autonomous vehicle to the first control input; and provide a second control input to the autonomous vehicle based on the grade of the roadway and the trailer load.

In some embodiments, the instructions further cause the processor to reduce a speed of the autonomous vehicle to maintain a lateral acceleration of the autonomous vehicle, and wherein the instructions further cause the processor to limit a steering wheel angle velocity to limit a lateral jerk of the autonomous vehicle.

In some embodiments, the instructions further cause the processor to: determine a type of the trailer load based on the response of the autonomous vehicle to the first control input; and cause the autonomous vehicle to accelerate up to a maximum acceleration that is based on the trailer load and a maximum jerk that is based on the type of the trailer load.

In some embodiments, the instructions further cause the processor to ensure that outermost points of the autonomous vehicle remain within inside edges of lane boundaries, unless the autonomous vehicle is changing lanes, doing a critical safety bias, evading, turning at an intersection, and/or the autonomous vehicle is unable to remain within the lane boundaries due to a combination of a width of the lane and a road curvature.

Another aspect is a method comprising: estimating a grade of a roadway based on perception data indicative of one or more parameters of the roadway received from one or more perception sensors of an autonomous vehicle; providing a first control input to the autonomous vehicle based on the grade of the roadway; determining a response of the autonomous vehicle to the first control input based on perception data indicative of a movement of the autonomous vehicle received from the one or more perception sensors; estimating a trailer load of the trailer based on the response of the autonomous vehicle to the first control input; and providing a second control input to the autonomous vehicle based on the grade of the roadway and the trailer load.

In some embodiments, the method further comprises: targeting a lateral position in a lane of the autonomous vehicle such that widest points of the autonomous vehicle are substantially equidistant from lane boundaries when driving straight, turning, or changing lanes, unless for an evasive maneuver, bias, or to minimize off-tracking.

In some embodiments, the method further comprises: monitoring any deviations from a targeted lateral position; and in response to determining that the autonomous vehicle has deviated from the targeted lateral position by more than a predetermined deviation distance, returning to the targeted lateral position within a predetermined deviation time.

In some embodiments, the method further comprises: detecting a school bus based on the perception data; detecting an extended stop sign arm of the school bus; and in response to detecting the extended stop sign arm, causing the autonomous vehicle to stop a predetermined distance away from the school bus.

In some embodiments, the method further comprises: detecting an animal on the roadway based on the perception data; determining that the animal is larger than a predetermined size; in response to determining that the animal is larger than a predetermined size, causing the autonomous vehicle to maintain a predetermined distance from the animal as the autonomous vehicle passes the animal.

Another aspect is an autonomous vehicle configured to drive on a roadway, comprising: at least one perception sensor configured to generate perception data indicative of roadway conditions; at least one global positioning system (GPS) receiving device configured to receive a GPS signal; a network communication subsystem configured to communicate with a remote oversight system; a processor; and a non-transitory computer readable medium configured to store mapped data and having stored thereon instructions that, when executed by the processor, cause the processor to: receive the perception data from the at least one perception sensor, generate roadway condition data based on the perception data, receive the GPS signal from the at least one GPS receiving device, retrieve the mapped data from the non-transitory computer readable medium, determine that the GPS signal meets a minimum localization accuracy requirement, combine the generated roadway condition data with the GPS signal to form detected road data, determine that there is a discrepancy between the detected road data and the retrieved mapped data, in response to the determining that there is a discrepancy between the detected road data and the retrieved mapped data, update the mapped data with the detected road data, and transmit the updated mapped data to the remote oversight system through the network communication subsystem.

In some embodiments, the at least one GPS receiving device is a plurality of GPS receiving devices located on different parts of the autonomous vehicle to improve a strength of the received GPS signal and a positioning accuracy of the GPS signal.

In some embodiments, in response to determining that the received GPS data does not meet the minimum localization accuracy requirement, the processor is further configured to cause the autonomous vehicle to perform a minimal risk condition (MRC) maneuver to stop the autonomous vehicle.

In some embodiments, the processor is further configured to cause the autonomous vehicle to stop at a shoulder of the roadway.

In some embodiments, the processor is further configured to communicate to the remote oversight system and request for assistance.

In some embodiments, the autonomous vehicle further comprises: a visual inertia odometry (VIO) configured to generate location data; and wherein when the received GPS signal does not meet the minimum localization accuracy requirement, the processor is further configured to: derive road positioning data from the VIO location data and the perception data received from the at least one perception sensor, and cause the autonomous vehicle to operate according to the derived road positioning data.

In some embodiments, the derived road positioning data comprises a road longitudinal data and a road lateral data, and wherein the road longitudinal data is derived from the VIO location data, and the road lateral data is derived from the perception data received from the at least one perception sensor.

In some embodiments, the road lateral data is derived at least in part from perception of a lane marking by the at least one perception sensor.

In some embodiments, the processor is further configured to cause the autonomous vehicle to operate in a tunnel where the GPS signal is unavailable or is inaccurate.

In some embodiments, the processor is further configured to cause the autonomous vehicle to operate in a parking building where the GPS signal does not meet the minimum localization accuracy requirement.

Another aspect is a method comprising: receiving perception data from at least one perception sensor of an autonomous vehicle; generating roadway condition data based on the perception data; receiving global positioning system (GPS) signal from at least one GPS receiving device of the autonomous vehicle; retrieving mapped data from a non-transitory computer readable medium of the autonomous vehicle; determining that the GPS signal meets a minimum localization accuracy requirement; combining the generated roadway condition data with the GPS signal to form detected road data; determining that there is a discrepancy between the detected road data and the retrieved mapped data; in response to the determining that there is a discrepancy between the detected road data and the retrieved mapped data, updating the mapped data with the detected road data; and transmitting the updated mapped data to the remote oversight system through a network communication subsystem.

In some embodiments, for each off-ramp exit on a limited access highway in the digital map a plurality of safety areas is marked within 5 miles from the off-ramp exit.

In some embodiments, each of the plurality of safety areas is at least 96 meters long and 3.4 meters wide.

In some embodiments, when the autonomous vehicle is a truck and a roadway is identified as restrictive to truck traffic, further comprising: finding a route excluding the roadway identified as restricted to truck traffic.

In some embodiments, the roadway identified restrictive to truck traffic is a roadway having a weight limit that is lower than a weight of the autonomous vehicle.

In some embodiments, the roadway and/or a lane of the roadway identified as restrictive to truck traffic is a roadway and/or a lane of the roadway having a no-truck-traffic sign.

In some embodiments, when a construction zone traffic sign and traffic control devices on a roadway are detected by the at least one perception sensor of the autonomous vehicle, further comprising: establishing a virtual wall separating the construction zone and the roadway; and causing the autonomous vehicle to stay at least a predetermined safe distance away from the virtual wall.

In some embodiments, the predetermined safe distance is 8% of a lane width of the roadway.

In some embodiments, the traffic control devices include at least a traffic control barricade, a traffic control cone, a traffic control barrel, and a construction zone flagger.

Another aspect is a non-transitory computer-readable medium having stored thereon mapped data and instructions which, when executed by a processor, cause the processor to: receive perception data from at least one perception sensor of an autonomous vehicle; generate roadway condition data based on the perception data; retrieve mapped data from the non-transitory computer readable medium of the autonomous vehicle; determine that a global positioning system (GPS) signal from at least one GPS receiving device of the autonomous vehicle meets a minimum localization accuracy requirement; combine the generated roadway condition data with the GPS signal to form a detected road data; determine that there is a discrepancy between the detected road data and the retrieved mapped data; in response to the determining that there is a discrepancy between the detected road data and the retrieved mapped data, update the mapped data with the detected road data; and transmit the updated mapped data to a remote oversight system through a network communication subsystem.

Another aspect is an autonomous vehicle comprising: at least one perception sensor configured to generate perception data indicative of physical infrastructure on or near a roadway; a processor; and a non-transitory computer readable medium having stored thereon instructions that, when executed by the processor, cause the processor to: determine a minimal risk condition (MRC) maneuver for the autonomous vehicle to execute, identify a safe zone in which the autonomous vehicle is able to execute the MRC maneuver by coming to a stop based at least in part on the perception data, identify one or more exclusion zones within the safe zone based on the perception data, and control the autonomous vehicle to execute the MRC maneuver including stopping outside of the one or more exclusion zones.

In some embodiments, the one or more exclusion zones comprise areas that are within a predetermined distance from an emergency vehicle.

In some embodiments, controlling the autonomous vehicle to execute the MRC maneuver includes controlling the autonomous vehicle to avoid entering the one or more exclusion zones while executing the MRC maneuver.

In some embodiments, the one or more exclusion zones comprise areas that are within a predetermined distance from a construction zone.

In some embodiments, the processor is further configured to avoid completing the MRC maneuver within a threshold distance from a crosswalk at an intersection.

In some embodiments, the autonomous vehicle further comprises: a cab including a human machine interface (HMI), wherein the processor is further configured to provide a visual and/or audio notification via the HMI.

In some embodiments, the autonomous vehicle further comprising: hazard lights that are externally visible from the autonomous vehicle, wherein controlling the autonomous vehicle to execute the MRC maneuver includes: controlling the autonomous vehicle to maneuver to a right-most lane, and in response to moving towards and/or reaching the right-most lane, activating the hazard lights.

In some embodiments, the processor is further configured to keep the hazard lights activated until deactivated by a human operator.

In some embodiments, the autonomous vehicle further comprises: a plurality of turn indicators, wherein the processor is further configured to set a usage of the plurality of turn indicators to supersede a usage of the hazard lights while executing the MRC maneuver.

In some embodiments, the processor is further configured to: control the autonomous vehicle to maintain a minimum lateral distance between an outer most point of the autonomous vehicle and a lane line that separates a driving lane from the safe zone at a closest point of approach when the autonomous vehicle comes to a stop during the MRC maneuver.

In some embodiments, controlling the autonomous vehicle to execute the MRC maneuver includes controlling the autonomous vehicle to come to a stop when the autonomous vehicle is completely within the safe zone and no part of the autonomous vehicle is intruding into a driving lane.

In some embodiments, the processor is further configured to cause the autonomous vehicle to yield to any approaching emergency vehicle that has activated its siren and/or emergency lights while the autonomous vehicle is executing the MRC maneuver.

In some embodiments, determining that the autonomous vehicle is to execute the MRC maneuver is further in response to determining that the autonomous vehicle is approaching a boundary of a map.

Another aspect is a non-transitory computer-readable medium having stored thereon instructions which, when executed by a processor, cause the processor to: determine a minimal risk condition (MRC) maneuver for an autonomous vehicle to execute; identify a safe zone in which the autonomous vehicle is able to execute the MRC maneuver by coming to a stop based on perception data received from at least one perception sensor of the autonomous vehicle, the at least one perception sensor configured to generate the perception data to be indicative of physical infrastructure on or near a roadway; identify one or more exclusion zones within the safe zone based on the perception data; and control the autonomous vehicle to execute the MRC maneuver including stopping outside of the one or more exclusion zones.

In some embodiments, the instructions further cause the processor to reduce speed of the autonomous vehicle to maintain a lateral acceleration of the autonomous vehicle.

In some embodiments, the instructions further cause the processor to: detect an equipment failure of the autonomous vehicle based on the perception data; determine a severity level of the equipment failure; and determine whether the autonomous vehicle is to execute the MRC maneuver or plan to visit a service station based on the severity level.

In some embodiments, the instructions further cause the processor to: determine that the severity level is less than a predetermined level; determine that the service station is within a predetermined distance from the autonomous vehicle based on the perception data; and determine a re-routing for the autonomous vehicle to visit the service station in response to determining that the severity level is less than the predetermined level, and determining that the service station is within the predetermined distance of the autonomous vehicle.

Another aspect is a method comprising: determining a minimal risk condition (MRC) maneuver for an autonomous vehicle to execute; identifying a safe zone in which the autonomous vehicle is able to execute the MRC maneuver by coming to a stop based on perception data received from at least one perception sensor of the autonomous vehicle, the at least one perception sensor configured to generate the perception data to be indicative of physical infrastructure on or near a roadway; identifying one or more exclusion zones within the safe zone based on the perception data; and controlling the autonomous vehicle to execute the MRC maneuver including stopping outside of the one or more exclusion zones.

In some embodiments, method further comprises: detecting a vertical clearance on a current path of the autonomous vehicle based on the perception data; and determining that the vertical clearance is greater than a vertical-clearance threshold value, wherein determining that the autonomous vehicle is to execute the MRC maneuver is further in response to determining that the vertical clearance is greater than the vertical clearance threshold value.

In some embodiments, the method further comprises: detecting a toll-booth facility based on the perception data; identifying a start point of the toll-booth facility based on detecting where highway lines start to spread out into a plurality of toll lanes; and identifying an end point of the toll-booth facility based on detecting where the plurality of toll lanes starts to merge back into the highway lanes.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of this disclosure, reference is now made to the following brief description, taken in connection with the accompanying drawings and detailed description, wherein like reference numerals represent like parts.

FIG. 1 illustrates a schematic diagram of a system including an autonomous vehicle;

FIG. 2 shows a flow diagram for operation of an autonomous vehicle (AV) safely in light of the health and surroundings of the AV; and

FIG. 3 illustrates a system that includes one or more autonomous vehicles, a control center or oversight system with a human operator (e.g., a remote center operator (RCO)), and an interface for third-party interaction.

FIG. 4A illustrates an example visualization of a fast reveal scenario in accordance with aspects of this disclosure.

FIGS. 4B-4C illustrate example visualizations of sudden braking scenarios in accordance with aspects of this disclosure.

FIG. 4D illustrates an example visualization of a lateral intrusion scenario in accordance with aspects of this disclosure.

FIG. 4E illustrates an example visualization of a cross path scenario in accordance with aspects of this disclosure.

FIG. 4F illustrates an example visualization of an oncoming scenario in accordance with aspects of this disclosure.

FIG. 4G illustrates an example visualization of a cut-in scenario in accordance with aspects of this disclosure.

FIG. 4H illustrates an example visualization of a non-compliant vehicle parallel to the autonomous vehicle in accordance with aspects of this disclosure.

FIG. 4I illustrates an example visualization of a speeding non-compliant vehicle in accordance with aspects of this disclosure.

FIG. 4J illustrates an example visualization of an oscillating non-compliant vehicle in accordance with aspects of this disclosure.

FIG. 4K illustrates an example visualization of an intersection non-compliant vehicle in accordance with aspects of this disclosure.

FIG. 4L illustrates an example visualization of a bumper-to-bumper gap and a lateral gap in accordance with aspects of this disclosure.

FIG. 4M illustrates an example method which can be used to control the autonomous vehicle based on the detection of a non-compliant vehicle.

FIG. 5A is a photo showing an example of a level crossing.

FIG. 5B is shows an example speed limit traffic sign.

FIG. 5C is shows an example do-not-pass traffic sign.

FIG. 5D is a schematic illustrating definition of a roadway grade.

FIG. 5E – FIG. 5L are photos showing different examples of grade traffic signs and driving advice signs.

FIG. 5M – FIG. 5Q are more examples of driving advice with grade signs.

FIG. 5R is schematic illustrating the definition of a superelevation road.

FIG. 5S is a block diagram illustrating the steps of driving through a superelevation road.

FIG. 5T – FIG. 5V show examples of road blockage traffic signs.

FIG. 5W – FIG. 5Y show examples of road blockage devices.

FIG. 5Z shows an example construction zone traffic sign by a roadside.

FIG. 5AA shows another example construction zone traffic sign.

FIG. 5AB shows a photo presenting an example traffic sign and traffic control devices (barricades) combination which define a virtual wall for a construction zone.

FIG. 5AC shows another photo presenting an example traffic sign and traffic control devices (barrels) combination which define a virtual wall for a construction zone.

FIG. 5AD and FIG. 5AE are schematics depicting example construction zone flaggers presenting stop and proceed signals.

FIG. 5AF - FIG. 5AJ are schematics illustrating traffic blockage and control devices.

FIG. 5AK is an example construction zone traffic sign.

FIG. 5AL is a photo showing speed limit reduction in a construction zone.

FIG. 5AM and FIG. 5AN are photos showing human traffic control (flaggers).

FIG. 5AO - FIG. 5AT are schematics for human traffic control (flaggers).

FIG. 5AU shows a roadway schematic having solid white lines illustrating lane closure at a construction zone.

FIG. 5AV is an example of a be-prepared-to-stop traffic sign illustrating lane closure at a construction zone.

FIG. 5AW shows a roadway schematic illustrating lane shift in a construction zone.

FIG. 5AX – FIG. 5BA are example traffic signs illustrating lane shift in a construction zone.

FIG. 5BB shows an example truck crossing traffic sign.

FIG. 5BC is a plan view schematic illustrating a diverging diamond interchange on a highway system.

FIG. 5BD is a plan view photo showing a full cloverleaf interchange on a highway system.

FIG. 5BE is a bird’s-eye view photo showing an interchange on a highway system.

FIG. 5BF is a table containing roundabout category data.

FIG. 5BG is an example mini roundabout traffic sign.

FIG. 5BH - 2BK show example roundabout traffic signs.

FIG. 5BL is a photo showing a two-way left turn lane (center lane).

FIG. 5BM and FIG. 5BN are two example two-way left turn lane traffic signs.

FIG. 5BO is a plan view schematic showing a two-way left turn lane in the middle of a roadway.

FIG. 5BP is a plan view schematic illustrating possible entry points into a two-way left turn lane in a roadway.

FIG. 5BQ shows an example traffic light traffic sign.

FIG. 5BR - 5BT are examples of intersection traffic signs.

FIG. 5BU and FIG. 5BV show no-turn-on-red and left-turn-yield-on-green traffic signs at intersections with traffic lights.

FIG. 5BY is a street photo showing part of a truck apron at a roundabout intersection.

FIG. 5BZ and FIG. 5CA are two plan schematics illustrating traffic circle intersections.

FIG. 5CB is a photo showing a fork road intersection.

FIG. 5CC is a plan view schematic illustrating an uncontrolled intersection.

FIG. 5CD is a plan view schematic illustrating a four-way intersection.

FIG. 5CE - 5CH show a plurality of crosswalk traffic signs as examples.

FIG. 5CI - 5CM show a plurality of crosswalk traffic signs as more examples.

FIG. 5CN is a plan view schematic illustrating an example dynamic zone in a roadway.

FIG. 5CO is a plan view schematic illustrating another example dynamic zone at an intersection.

FIG. 5CP - 5CT show photos depicting different lane boundaries.

FIG. 5CU is a photo showing lane restriction by traffic signal.

FIG. 5CV is a photo showing lane restriction by movable physical barrier.

FIG. 5CW - 5DB are example traffic signs indicating fixed zones.

FIG. 5DC is a photo showing a lighted street in the night.

FIG. 5DD is a photo showing the inside of a tunnel with lighting.

FIG. 5DE and FIG. 5DF are plan view schematics showing entry ramps on highways.

FIG. 5DG - 5DI are plan view schematics showing exit ramps on highways.

FIG. 5DJ is a plan view schematic illustrating a cloverleaf ramp on a highway.

FIG. 5DK is a photo showing an entry ramp traffic sign standing at a road boundary.

FIG. 5DL is a plan view schematic illustrating a parallel lane as part of an entry ramp on a highway.

FIG. 5DM is a plan view schematic illustrating an exit ramp on a highway.

FIG. 5DN is an example technique for operating an autonomous vehicle on a roadway with a grade.

FIGS. 6A and 6B illustrate example visualizations of the periodically updated map in accordance with aspects of this disclosure.

FIGS. 6C and 6D illustrate example visualizations of the safe zones on or near the roadway in accordance with aspects of this disclosure.

FIGS. 6E-6G illustrate example visualizations of traffic signs that may identify icy conditions in accordance with aspects of this disclosure.

FIG. 6H illustrates an example visualization of a traffic sign that may identify a fog area in accordance with aspects of this disclosure.

FIGS. 6I-6K illustrate example visualizations of lighting zones in accordance with aspects of this disclosure.

FIGS. 6L-6O illustrate example visualizations of traffic signs that may identify that the use of headlights is appropriate in accordance with aspects of this disclosure.

FIGS. 6P-6R illustrate example visualizations of traffic signs that may identify that the use of headlights is required in accordance with aspects of this disclosure.

FIG. 6S illustrates an example visualization of one or more entities which are within the autonomous vehicle’s lighting zone in accordance with aspects of this disclosure.

FIG. 6T illustrates an example method which can be used to control the autonomous vehicle taking into account environmental conditions detected by at least one perception sensor.

FIG. 7A illustrates an example visualization of the forces (e.g., lateral resistive forces) which may be relevant to an autonomous vehicle driving on a roadway with an incline.

FIGS. 7B-7C illustrate example visualizations of yield signs.

FIGS. 7D-7E illustrate example visualizations of no turn signs.

FIG. 7F illustrates an example visualization of a no right turn sign.

FIGS. 7G-7I illustrate example visualizations of signs which have right turn only lanes.

FIGS. 7J-K illustrate example visualizations of no left turn signs.

FIGS. 7L-7M illustrate example visualizations of signs which have left turn only lanes.

FIG. 7N illustrates an example visualization of a no trucks sign.

FIGS. 7O-7V illustrate example visualizations of pedestrian crossing signs.

FIG. 7W illustrates an example visualization of a truck route sign.

FIG. 7X-7AC illustrate example visualizations of weight limit signs.

FIG. 7AD-7AF illustrate example visualizations of road closure signs.

FIG. 7AG-7AK illustrate example visualizations of mandatory freeway exit signs.

FIG. 7AL-7AZ illustrate example visualizations of environment precaution signs.

FIG. 7BA-7BB illustrate example visualizations of reduced speed limit ahead signs.

FIG. 7BC-7BJ illustrate example visualizations of merging signs.

FIG. 7BK-7BT illustrate example visualizations of non-vehicular warning signs.

FIG. 7BU-BX illustrate example visualizations of advanced turn signs.

FIG. 7BY illustrates an example method which can be used to control the autonomous vehicle based on the estimation of the trailer load.

FIG. 8A is a photo showing an example limited access highway.

FIG. 8B is a photo showing an example single-lane road.

FIG. 8C is a photo showing an example multi-lane road.

FIG. 8D is a photo showing an example median between the opposing direction lanes of a highway.

FIG. 8E is a photo of an example one-way road where traffic drives only in a single direction as indicated by a traffic sign.

FIG. 8F schematically illustrates an example frontage road in parallel and connected to a highway.

FIG. 8G schematically illustrates an example on-ramp from an undivided arterial road to a limited access highway.

FIG. 8H is a photo showing an example off-ramp to allow a vehicle to exit a limited access highway.

FIG. 8I schematically illustrates a gore area between the outside lane of a highway and an on-ramp.

FIG. 8J is a photo showing an example merge area starting at a gore point and finishing when the merged lane boundaries are the same width as the surrounding lanes.

FIG. 8K is a photo showing an example local merge area indicated by traffic signs “left lane ends” and “merge right”.

FIG. 8L schematically illustrates a roadway with an emergency lane outside of drivable lanes as part of a map extension.

FIG. 8M is a photo showing an example of a part time shoulder lane on a divided highway as indicated by an arrow light.

FIGS. 8N - 8Q are examples of different traffic signs to indicate that an emergency lane can be used as an evaculane for different evacuation purposes.

FIG. 8R is a photo showing an example intersection.

FIG. 8S is a photo showing an example of a temporary merge lane just before an off-ramp.

FIG. 8T is a photo showing an example express lane as indicated by a traffic sign.

FIG. 8U is a photo showing an example high-occupancy vehicle (HOV) lane as indicated by a traffic sign.

FIG. 8V is a photo showing an HOV lane entrance on a highway.

FIG. 8W is a photo showing a high-occupancy toll (HOT) road entrance station available to high-occupancy vehicles and other vehicles that pay a toll to use.

FIG. 8X schematically illustrates a center lane located in the middle of a two-way street, in which traffic may travel in either direction and make left turns.

FIG. 8Y is a photo showing an example of a truck lane.

FIG. 8Z is a photo showing an example of a bicycle lane.

FIG. 8AA is a photo showing an example of bus lanes.

FIG. 8AB schematically illustrates a slip lane at an intersection.

FIG. 8AC is a photo showing an example of a slip lane at an intersection.

FIG. 8AD is a schematic showing a merge through lane and a merge ending lane.

FIG. 8AE schematically illustrates a sidewalk defined between a curb and a boundary.

FIG. 8AF is a photo showing a crosswalk with spaced zebra markings intersecting a driveway.

FIG. 8AG is a photo showing an example of a tunnel with an entrance.

FIG. 8AH is a photo showing an example driveway from a local roadway to a gas station.

FIG. 8AI is a photo showing a no trucks lane on a highway.

FIG. 8AJ and FIG. 8AK show examples of one-way traffic signs.

FIG. 8AL and FIG. 8AM show examples of uneven road surface traffic signs.

FIG. 8AN shows an example of a soft shoulder traffic sign.

FIG. 8AO - 8AR are examples of traffic signs for road surface conditions.

FIG. 8AS shows an example of a falling rocks on road traffic sign.

FIG. 8AT and FIG. 8AU are photos showing two example zone flaggers, each holding a stop/slow paddle.

FIG. 8AV is a photo showing a construction zone flagger using a “stop road users” hand signal to stop oncoming vehicles.

FIG. 8AW is a schematic showing a construction zone flagger using a “proceed road users” hand signal to allow oncoming vehicles to move forward.

FIG. 8AX is a photo showing a construction zone flagger using a “proceed road users” hand signal to allow oncoming vehicles to move forward.

FIG. 8AY is a schematic showing a construction zone flagger using a “slow road users” hand signal to slow down oncoming vehicles.

FIG. 8AZ is a photo showing a construction zone flagger using a “slow road users” hand signal to slow down oncoming vehicles.

FIG. 8BA - 8BD are examples of construction zone traffic signs.

FIG. 8BE - 8BI are examples of lane closure traffic signs.

FIG. 8BJ shows an example of a detour traffic sign.

FIG. 8BK - 8BM show examples of speed limit signs together with other traffic signs.

FIG. 8BN - 8BP show examples of end of construction zone traffic signs.

FIG. 8BQ - 8BS show examples of construction zone flagger’s hand signal devices including stop/slow paddles and a flag.

FIG. 8BT - 8CB schematically present construction zone flagger’s hand signaling.

FIG. 8CC - 8CG show weight limitation traffic signs.

FIG. 8CH - 8CQ show ongoing road construction traffic signs.

FIG. 8CR is a photo showing a road narrowing traffic sign standing by a roadside.

FIG. 8CS - 8CU are photos showing examples of road restriction signs.

FIG. 8CV - 8CZ are photos showing examples of traffic control devices.

FIG. 8DA shows an example of a merge traffic sign.

FIG. 8DB is a block diagram showing an example technique for updating the digital map based on real time data from an autonomous vehicle.

FIG. 9A illustrates an example visualization of a first MRC maneuver for an example scenario in where there are no external complications.

FIG. 9B illustrates an example visualization of a first MRC maneuver for a first example scenario in which the autonomous vehicle is performing a left lane change.

FIG. 9C illustrates an example visualization of a first MRC maneuver for a second example scenario in which the autonomous vehicle is performing a left lane change.

FIG. 9D illustrates an example visualization of a first MRC maneuver for an example scenario in which the autonomous vehicle is performing a right lane change.

FIG. 9E illustrates an example visualization of a first MRC maneuver for an example scenario in which the safe area is taken or occupied.

FIG. 9F illustrates an example visualization of a first MRC maneuver for an example scenario in which an ELV is located in the safe area.

FIG. 9G illustrates an example visualization of a first MRC maneuver for an example scenario in which the autonomous vehicle is approaching a map boundary.

FIG. 9H illustrates an example visualization of a first MRC maneuver for an example scenario in which the autonomous vehicle has missed an exit.

FIG. 9I illustrates an example visualization of a first MRC maneuver for an example scenario in which the autonomous vehicle has been forced off route.

FIGS. 9J-9L illustrate example visualizations of service station signs.

FIGS. 9M-9N illustrate example visualizations of service station signs indicating that a service station is either open or closed.

FIG. 9O illustrates an example visualization of a service station that can include one or more signs having instructions.

FIGS. 9P-9R illustrate example visualizations of signs that can be located in a service station.

FIG. 9S illustrates an example visualization of one or more queues at a service station.

FIG. 9T illustrates an example visualization of a bridge which has a vertical clearance.

FIGS. 9U-9X illustrate example visualizations of signs that may indicate the presence of a low clearance area or object ahead.

FIG. 9Y-9AB illustrate example visualizations of signs that may indicate the presence of a weigh station ahead.

FIG. 9AC-9AE illustrate example visualizations of signs and signals that may indicate whether a weigh station is open or closed.

FIG. 9AF-9AI illustrate example visualizations of toll booth facilities.

FIG. 9AJ-9AL illustrate example visualizations of toll booth facilities including traffic signs indicating whether the corresponding toll booths are open or closed.

FIG. 9AM-9AP illustrate example visualizations of a map and signs that indicate the presence of toll booths.

FIG. 9AQ-9AR illustrate example visualizations of signs indicating the toll payment types accepted by a corresponding toll lane.

FIG. 9AS illustrates an example visualization of a front distance between the autonomous vehicle and a target lane front vehicle.

FIG. 9AT illustrates an example visualization of a toll booth facility.

FIG. 9AU illustrates an example visualization of a ramp with a ramp meter.

FIG. 9AV-9AZ illustrate example visualizations of signs that can indicate the presence of a ramp meter.

FIG. 9BA-9BC illustrate example visualizations of signs that can indicate flow control schemes.

FIG. 9BD-9BE illustrate example visualizations of signs and/or flashing lights that can indicate the presence of a ramp meter.

FIG. 9BF-9BI illustrate example visualizations of signs and/or flashing lights that can indicate the presence of ramp meter traffic lights and flow control schemes.

FIG. 9BJ illustrates an example visualization of traffic stopped at a ramp meter.

FIG. 9BK illustrates an example visualization of merging traffic.

FIG. 9BL illustrates an example visualization of a speed bump.

FIG. 9BM-9BO illustrate example visualizations of speed humps.

FIG. 9BP illustrates an example visualization of a speed cushion.

FIG. 9BQ illustrates an example visualization of a speed table.

FIG. 9BR illustrates an example visualization of a portable speed bump.

FIG. 9BS illustrates an example visualization of a sign indicating the presence of a speed hump.

FIG. 9BT illustrates an example visualization of a speed bump and a sign indicating a speed limit for the speed bump.

FIG. 9BU illustrates an example visualization of a speed table with a cross walk.

FIG. 9BV illustrates an example visualization of a pothole.

FIG. 9BW illustrates an example visualization of a roadway with shoulders.

FIG. 9BX illustrates an example visualization of a highway with a shoulder.

FIG. 9BY-9CA illustrate example visualizations of roadways having different widths.

FIG. 9CB-9CD illustrate example visualizations of signs that indicate whether trucks are permitted in a given lane or roadway.

FIG. 9CE illustrates an example visualization of the vertical clearance of a tunnel.

FIG. 9CF-9CG illustrate example visualizations of a tunnel and signs that indicate the vertical clearance for tunnels.

FIG. 9CH illustrates an example visualization of a sign indicating that headlight should be used in the upcoming tunnel.

FIG. 9CI illustrates an example method which can be used to control the autonomous vehicle during an MRC maneuver.

DETAILED DESCRIPTION

Vehicles traversing highways and roadways are legally required to comply with regulations and statutes in the course of safe operation of the vehicle. For autonomous vehicles (AVs), particularly autonomous tractor trailers, the ability to recognize a malfunction in its systems and stop safely are necessary for lawful and safe operation of the vehicle. Described below in detail are systems and methods for the safe and lawful operation of an autonomous vehicle on a roadway, including the execution of maneuvers that bring the autonomous vehicle in compliance with the law while signaling surrounding vehicles of its condition.

Overview of Autonomous Vehicles

FIG. 1 shows a system 100 that includes a tractor 105 of an autonomous truck. The tractor 105 includes a plurality of vehicle subsystems 140 and an in-vehicle control computer 150. The plurality of vehicle subsystems 140 includes vehicle drive subsystems 142, vehicle sensor subsystems 144, and vehicle control subsystems. An engine or motor, wheels and tires, a transmission, an electrical subsystem, and a power subsystem may be included in the vehicle drive subsystems. The engine of the autonomous truck may be an internal combustion engine, a fuel-cell powered electric engine, a battery powered electrical engine, a hybrid engine, or any other type of engine capable of moving the wheels on which the tractor 105 moves. The tractor 105 may have multiple motors or actuators to drive the wheels of the vehicle, such that the vehicle drive subsystems 142 include two or more electrically driven motors. The transmission may include a continuous variable transmission or a set number of gears that translate the power created by the engine into a force that drives the wheels of the vehicle. The vehicle drive subsystems may include an electrical system that monitors and controls the distribution of electrical current to components within the system, including pumps, fans, and actuators. The power subsystem of the vehicle drive subsystem may include components that regulate the power source of the vehicle.

Vehicle sensor subsystems 144 can include sensors for general operation of the autonomous truck 105, including those which would indicate a malfunction in the AV or another cause for an AV to perform a limited or minimal risk condition (MRC) maneuver. The sensors for general operation of the autonomous vehicle may include cameras, a temperature sensor, an inertial sensor (IMU), a global positioning system, a light sensor, a LIDAR system, a radar system, and wireless communications.

A sound detection array, such as a microphone or array of microphones, may be included in the vehicle sensor subsystem 144. The microphones of the sound detection array are configured to receive audio indications of the presence of, or instructions from, authorities, including sirens and command such as “Pull over.” These microphones are mounted, or located, on the external portion of the vehicle, specifically on the outside of the tractor portion of an autonomous truck 105. Microphones used may be any suitable type, mounted such that they are effective both when the autonomous truck 105 is at rest, as well as when it is moving at normal driving speeds.

Cameras included in the vehicle sensor subsystems 144 may be rear facing so that flashing lights from emergency vehicles may be observed from all around the autonomous truck 105. These cameras may include video cameras, cameras with filters for specific wavelengths, as well as any other cameras suitable to detect emergency vehicle lights based on color, flashing, of both color and flashing.

The vehicle control subsystem 146 may be configured to control operation of the autonomous vehicle, or truck, 105 and its components. Accordingly, the vehicle control subsystem 146 may include various elements such as an engine power output subsystem, a brake unit, a navigation unit, a steering system, and an autonomous control unit. The engine power output may control the operation of the engine, including the torque produced or horsepower provided, as well as provide control the gear selection of the transmission. The brake unit can include any combination of mechanisms configured to decelerate the autonomous vehicle 105. The brake unit can use friction to slow the wheels in a standard manner. The brake unit may include an Anti-lock brake system (ABS) that can prevent the brakes from locking up when the brakes are applied. The navigation unit may be any system configured to determine a driving path or route for the autonomous vehicle 105. The navigation unit may additionally be configured to update the driving path dynamically while the autonomous vehicle 105 is in operation. In some embodiments, the navigation unit may be configured to incorporate data from the GPS device and one or more predetermined maps so as to determine the driving path for the autonomous vehicle 105. The steering system may represent any combination of mechanisms that may be operable to adjust the heading of autonomous vehicle 105 in an autonomous mode or in a driver-controlled mode.

The autonomous control unit may represent a control system configured to identify, evaluate, and avoid or otherwise negotiate potential obstacles in the environment of the autonomous vehicle 105. In general, the autonomous control unit may be configured to control the autonomous vehicle 105 for operation without a driver or to provide driver assistance in controlling the autonomous vehicle 105. In some embodiments, the autonomous control unit may be configured to incorporate data from the GPS device, the RADAR, the LiDAR (i.e., LIDAR), the cameras, and/or other vehicle subsystems to determine the driving path or trajectory for the autonomous vehicle 105. The autonomous control that may activate systems that the AV 105 has which are not present in a conventional vehicle, including those systems which can allow an AV to communicate with surrounding drivers or signal surrounding vehicles or drivers for safe operation of the AV.

An in-vehicle control computer 150, which may be referred to as a VCU, includes a vehicle subsystem interface 160, a driving operation module 168, one or more processors 170, a compliance module 166, a memory 175, and a network communications subsystem 178. This in-vehicle control computer 150 controls many, if not all, of the operations of the autonomous truck 105 in response to information from the various vehicle subsystems 140. The one or more processors 170 execute the operations that allow the system to determine the health of the AV, such as whether the AV has a malfunction or has encountered a situation requiring service or a deviation from normal operation and giving instructions. Data from the vehicle sensor subsystems 144 is provided to VCU 150 so that the determination of the status of the AV can be made. The compliance module 166 determines what action should be taken by the autonomous truck 105 to operate according to the applicable (i.e., local) regulations. Data from other vehicle sensor subsystems 144 may be provided to the compliance module 166 so that the best course of action in light of the AV’s status may be appropriately determined and performed. Alternatively, or additionally, the compliance module 166 may determine the course of action in conjunction with another operational or control module, such as the driving operation module 168.

The memory 175 may contain additional instructions as well, including instructions to transmit data to, receive data from, interact with, or control one or more of the vehicle drive subsystems 142, the vehicle sensor subsystem 144, and the vehicle control subsystem 146 including the autonomous Control system. The in-vehicle control computer (VCU) 150 may control the function of the autonomous vehicle 105 based on inputs received from various vehicle subsystems (e.g., the vehicle drive subsystems 142, the vehicle sensor subsystem 144, and the vehicle control subsystem 146). Additionally, the VCU 150 may send information to the vehicle control subsystems 146 to direct the trajectory, velocity, signaling behaviors, and the like, of the autonomous vehicle 105. The autonomous control vehicle control subsystem may receive a course of action to be taken from the compliance module 166 of the VCU 150 and consequently relay instructions to other subsystems to execute the course of action.

FIG. 2 shows a flow diagram for operation of an autonomous vehicle (AV) safely in light of the health and surroundings of the AV. Although this figure depicts functional steps in a particular order for purposes of illustration, the process is not limited to any particular order or arrangement of steps. One skilled in the relevant art will appreciate that the various steps portrayed in this figure could be omitted, rearranged, combined and/or adapted in various ways.

As shown in FIG. 2 , the vehicle sensor subsystem 144 receives visual, auditory, or both visual and auditory signals indicating the at the environmental condition of the AV, as well as vehicle health or sensor activity data are received in step 205. These visual and/or auditory signal data are transmitted from the vehicle sensor subsystem 144 to the in-vehicle control computer system (VCU) 150, as in step 210. Any of the driving operation module and the compliance module receive the data transmitted from the vehicle sensor subsystem, in step 215. Then, one or both of those modules determine whether the current status of the AV can allow it to proceed in the usual manner or that the AV needs to alter its course to prevent damage or injury or to allow for service in step 220. The information indicating that a change to the course of the AV is needed may include an indicator of sensor malfunction; an indicator of a malfunction in the engine, brakes, or other components necessary for the operation of the autonomous vehicle; a determination of a visual instruction from authorities such as flares, cones, or signage; a determination of authority personnel present on the roadway; a determination of a law enforcement vehicle on the roadway approaching the autonomous vehicle, including from which direction; and a determination of a law enforcement or first responder vehicle moving away from or on a separate roadway from the autonomous vehicle. This information indicating that a change to the AV’s course of action is needed may be used by the compliance module to formulate a new course of action to be taken which accounts for the AV’s health and surroundings, in step 225. The course of action to be taken may include slowing, stopping, moving into a shoulder, changing route, changing lane while staying on the same general route, and the like. The course of action to be taken may include initiating communications with any oversight or human interaction systems present on the autonomous vehicle. The course of action to be taken may then be transmitted from the VCU 150 to the autonomous control system, in step 230. The vehicle control subsystems 146 then cause the autonomous truck 105 to operate in accordance with the course of action to be taken that was received from the VCU 150 in step 235.

It should be understood that the specific order or hierarchy of steps in the processes disclosed herein is an example of exemplary approaches. Based upon design preferences, it is understood that the specific order or hierarchy of steps in the processes may be rearranged while remaining within the scope of the present disclosure. The accompanying method claims present elements of the various steps in a sample order and are not meant to be limited to the specific order or hierarchy presented.

Autonomous Truck Oversight System

FIG. 3 illustrates a system 300 that includes one or more autonomous vehicles 105, a control center or oversight system 350 with a human operator 355, and an interface 362 for third-party 360 interaction. A human operator 355 may also be known as a remoter center operator (RCO). Communications between the autonomous vehicles 105, oversight system 350 and user interface 362 take place over a network 370. In some instances, where not all the autonomous vehicles 105 in a fleet are able to communicate with the oversight system 350, the autonomous vehicles 105 may communicate with each other over the network 370 or directly. As described with respect to FIG. 1 , the VCU 150 of each autonomous vehicle 105 may include a module for network communications 178.

An autonomous truck may be in communication with an oversight system. The oversight system may serve many purposes, including: tracking the progress of one or more autonomous vehicles (e.g., an autonomous truck); tracking the progress of a fleet of autonomous vehicles; sending maneuvering instructions to one or more autonomous vehicles; monitoring the health of the autonomous vehicle(s); monitoring the status of the cargo of each autonomous vehicle in contact with the oversight system; facilitate communications between third parties (e.g., law enforcement, clients whose cargo is being carried) and each, or a specific, autonomous vehicle; allow for tracking of specific autonomous trucks in communication with the oversight system (e.g., third-party tracking of a subset of vehicles in a fleet); arranging maintenance service for the autonomous vehicles (e.g., oil changing, fueling, maintaining the levels of other fluids); alerting an affected autonomous vehicle of changes in traffic or weather that may adversely impact a route or delivery plan; pushing over the air updates to autonomous trucks to keep all components up to date; and other purposes or functions that improve the safety for the autonomous vehicle, its cargo, and its surroundings. An oversight system may also determine performance parameters of an autonomous vehicle or autonomous truck, including any of: data logging frequency, compression rate, location, data type; communication prioritization; how frequently to service the autonomous vehicle (e.g., how many miles between services); when to perform an MRC maneuver while monitoring the vehicle’s progress during the maneuver; when to hand over control of the autonomous vehicle to a human driver (e.g., at a destination yard); ensuring an autonomous vehicle passes pre-trip inspection; ensuring an autonomous vehicle performs or conforms to legal requirements at checkpoints and weight stations; ensuring an autonomous vehicle performs or conforms to instructions from a human at the site of a roadblock, cross-walk, intersection, construction, or accident; and the like.

Included in some of the functions executed by an oversight system or command center is the ability to relay over-the-air, real-time weather updates to autonomous vehicles in a monitored fleet. The over-the-air weather updates may be pushed to all autonomous vehicles in the fleet or may be pushed to autonomous vehicles currently on a mission to deliver a cargo. Alternatively, or additionally, priority to push or transmit over-the-air weather reports may be given to fleet vehicles currently on a trajectory or route that leads towards or within a predetermined radius of a severe weather event.

Another function that may be encompassed by the functions executed by an oversight system or command center is the transmission of trailer metadata to the autonomous vehicle’s computing unit (VCU) prior to the start of a cargo transport mission. The trailer metadata may include the type of cargo being transmitted, the weight of the cargo, temperature thresholds for the cargo (e.g., trailer interior temperature should not fall below or rise above predetermined temperatures), time-sensitivities, acceleration/deceleration sensitivities (e.g., jerking motion may be bad because of the fragility of the cargo), trailer weight distribution along the length of the trailer, cargo packing or stacking within the trailer, and the like.

To allow for communication between autonomous vehicles in a fleet and an oversight system or command center, each autonomous vehicle may be equipped with a communication gateway. The communication gateway may have the ability to do any of the following: allow for AV to oversight system communication (i.e. V2C) and the oversight system to AV communication (C2V); allow for AV to AV communication within the fleet (V2V); transmit the availability or status of the communication gateway; acknowledge received communications; ensure security around remote commands between the AV and the oversight system; convey the AV’s location reliably at set time intervals; enable the oversight system to ping the AV for location and vehicle health status; allow for streaming of various sensor data directly to the command or oversight system; allow for automated alerts between the AV and oversight system; comply to ISO 21434 standards; and the like.

An oversight system or command center may be operated by one or more human, also known as an operator or an RCO. The operator may set thresholds for autonomous vehicle health parameters, so that when an autonomous vehicle meets or exceeds the threshold, precautionary action may be taken. Examples of vehicle health parameters for which thresholds may be established by an operator may include any of: fuel levels; oil levels; miles traveled since last maintenance; low tire-pressure detected; cleaning fluid levels; brake fluid levels; responsiveness of steering and braking subsystems; Diesel exhaust fluid (DEF) level; communication ability (e.g., lack of responsiveness); positioning sensors ability (e.g., GPS, IMU malfunction); impact detection (e.g., vehicle collision); perception sensor ability (e.g., camera, LIDAR, radar, microphone array malfunction); computing resources ability (e.g., VCU or ECU malfunction or lack of responsiveness, temperature abnormalities in computing units); angle between a tractor and trailer in a towing situation (e.g., tractor-trailer, 18-wheeler, or semi-truck); unauthorized access by a living entity (e.g., a person or an animal) to the interior of an autonomous truck; and the like. The precautionary action may include execution of an MRC maneuver, seeking service, or exiting a highway or other such re-routing that may be less taxing on the autonomous vehicle. An autonomous vehicle whose system health data meets or exceeds a threshold set at the oversight system or by the operator may receive instructions that are automatically sent from the oversight system to perform the precautionary action.

The operator may be made aware of situations affecting one or more autonomous vehicles in communication with or being monitored by the oversight system that the affected autonomous vehicle(s) may not be aware of. Such situations may include: irregular or sudden changes in traffic flow (e.g., traffic jam or accident); abrupt weather changes; abrupt changes in visibility; emergency conditions (e.g., fire, sinkhole, bridge failure); power outage affecting signal lights; unexpected road work; large or ambiguous road debris (e.g., object unidentifiable by the autonomous vehicle); law enforcement activity on the roadway (e.g., car chase or road clearing activity); and the like. These types of situations that may not be detectable by an autonomous vehicle may be brought to the attention of the oversight system operator through traffic reports, law enforcement communications, data from other vehicles that are in communication with the oversight system, reports from drivers of other vehicles in the area, and similar distributed information venues. An autonomous vehicle may not be able to detect such situations because of limitations of sensor systems or lack of access to the information distribution means (e.g., no direct communication with weather agency). An operator at the oversight system may push such information to affected autonomous vehicles that are in communication with the oversight system. The affected autonomous vehicles may proceed to alter their route, trajectory, or speed in response to the information pushed from the oversight system. In some instances, the information received by the oversight system may trigger a threshold condition indicating that MRC (minimal risk condition) maneuvers are warranted; alternatively, or additionally, an operator may evaluate a situation and determine that an affected autonomous vehicle should perform an MRC maneuver and subsequently send such instructions to the affected vehicle. In these cases, each autonomous vehicle receiving either information or instructions from the oversight system or the oversight system operator uses its on-board computing unit (i.e., VCU) to determine how to safely proceed, including performing an MRC maneuver that includes pulling-over or stopping.

Other interactions that the RCO may have with an autonomous vehicle or a fleet of autonomous vehicle includes any of the following: pre-planned event avoidance; real-time route information updates; real-time route feedback; trail hookup status; first responder communication request handling; notification of aggressive surrounding vehicle(s); identification of construction zone changes; status of an AV with respect to its operational design domain (ODD), such as alerting the RCO when an autonomous vehicle is close to or enters a status out of ODD; RCO notification of when an AV is within a threshold distance from a toll booth and appropriate instruction/communication with the AV or toll authority may be sent to allow the AV to bypass the toll; RCO notification of when an AV bypasses a toll; RCO notification of when an AV is within a threshold distance from a weigh station and appropriate instruction/communication with the AV or appropriate authority may be sent to allow the AV to bypass the weigh station; RCO notification of when an AV bypasses a weigh station; notification to the AV from the RCO regarding scheduling or the need for fueling or maintenance; RCO authorization of third-party access to an autonomous vehicle cab; ability of an RCO to start/restart an autonomous driving system (ADS) on a vehicle; ability of an administrator (possibly an RCO) to set roles for system users, including ground crew, law enforcement, and third parties (e.g., customers, owners of the cargo); support from a RCO for communication with a service maintenance system with fleet vehicles; notification to the RCO from an AV of acceleration events; instruction from a RCO to an AV to continue its mission even when communication is interrupted; RCO monitoring of an AV during and after an MRC maneuver is executed; support for continuous communication between an AV and a yard operator at facility where the AV is preparing to begin a mission or where the AV is expected to arrive; oversight system monitoring of software systems on an AV and oversight system receiving alerts when software systems are compromised; and the like.

An oversight system or command center may allow a third party to interact with the oversight system operator, with an autonomous truck, or with both the human system operator and an autonomous truck. A third party may be a customer whose goods are being transported, a law enforcement or emergency services provider, or a person assisting the autonomous truck when service is needed. In its interaction with a third party, the oversight system may recognize different levels of access, such that a customer concerned about the timing or progress of a shipment may only be allowed to view status updates for an autonomous truck, or may be able to view status and provide input regarding what parameters to prioritize (e.g., speed, economy, maintaining originally planned route) to the oversight system. By providing input regarding parameter prioritization to the oversight system, a customer can influence the route and/or operating parameters of the autonomous truck.

Features of an Autonomous Driving System in an Autonomous Truck

Actions that an autonomous vehicle, particularly an autonomous truck, as described herein may be configured to execute to safely traverse a course while abiding by the applicable rules, laws, and regulations may include those actions successfully accomplished by an autonomous truck driven by a human. These actions, or maneuvers, may be described as features of the truck, in that these actions may be executable instructions stored on the VCU 150 (i.e., the in-vehicle control computer unit). These actions or features may include those related to reactions to the detection of certain types of conditions or objects such as: behaving appropriately when encountering emergency lane vehicles on the highway; interacting with stopped vehicles on the roadway; perform evasive maneuvers in emergency situations; classify, track, and autonomously respond to motorcycles; be able to handle all levels of traffic autonomously; be able to detect and analyze objects within its field of view (FOV); maintain position within a given lane of travel; control, optimize, and maintain vehicle speed autonomously; properly identify and respond to both active and inactive railway crossings; interpret law enforcement behaviors and properly respond and defer to an on-board operator or yard operator, if needed; autonomously navigate accident areas; autonomously respond to roadway crashes and accidents; identify and autonomously interact with school buses; detect and respond to animals while causing the least harm; navigate a parking lot and park; identify and navigate low vertical clearance situations; detect when out-of-ODD and execute the proper MRC; operate within zones with constant definition (e.g., fixed zones, school zone); dynamic driving tasks; detect and respond to oncoming traffic; navigate weigh stations; navigate through tunnels; classify roadway traction properly respond; identify and operate in dynamic zones (e.g., zones with variable rules for time of day or day of the week); navigate toll road or toll booths; identify and respond to traffic signs; detect roadway grades (incline) for operational limits as defined in ODD (operational design domain); detect and track roadway superelevation for operational limits as defined in ODD; navigate areas with reduced localization sensor reliability; operate within unmapped construction zones; classify and navigate road blockages; operate within mapped construction zones; detect and navigate a service station; collect and transmit information about roadway misuse; navigate roadways with restricted lanes; obey human traffic controller; properly operate on roadways that are not entirely covered with water when road friction is sufficient for operation; detect icy roads and classify the severity of icing; navigate intersections; navigate freeway/highway interchanges; continued operation during periods of low wireless communications; operations in all lighting conditions; operation in all roadway types defined in the operational design domain; utilize road should appropriately; monitor other vehicles behavior for possible hijacking; respond appropriately to traffic lights; operate in inclement weather; and the like.

Other features of an autonomous truck may include those actions or features which are needed for any type of maneuvering, including that needed to accomplish the features or actions that are reactionary, listed above. Such features, which may be considered supporting features, may include: the ability to navigate roundabouts; the ability to properly illuminate with on-vehicle lights as-needed for ambient light and for compliance with local laws; apply the minimum amount of deceleration needed for any given action; determine location at all times; adapting dynamic vehicle control for trailer load distributions, excluding wheel adjustment; launching (reaching target speed), accelerating, stopping, and yielding; operate on roadways with bumps and potholes; enter an MRC on roadway shoulders; access local laws and regulations based on location along a route; operate on asphalt, concrete, mixed grading, scraped road, and gravel; ability to operate in response to metering lights/signals at on-ramps; operate on a roadway with a width up to a predetermined width; able to stop at crosswalks with sufficient stopping distance; navigate two-way left turn lanes; operate on roadways with entry and exit ramps; utilize the vehicle horn to communicate with other drivers; and the like. These supporting features, as well as the reactionary features listed above, may include controlling or altering the steering, engine power output, brakes, or other vehicle control subsystems 146.

Situational Behavior

The autonomous vehicle 105 can be configured to adjust its actions or maneuvers based on the detection of various different situations that the autonomous vehicle 105 may encounter. For example, the autonomous vehicle 105 can be configured to, under normal or optimal conditions, operate according to a default decision framework. Upon detecting a specific set of conditions that are consistent with a define situation, the autonomous vehicle 105 can be configured to alter the default decision framework in order to take certain actions that can improve safety for both the autonomous vehicle 105 and other entities on or near the roadway. Thus, it is desirable for the autonomous vehicle 105 to be able to identify certain predefined situations and modify the autonomous vehicle’s 105 behavior in response to detecting one of the predefined situations in order to safely manage the detected situation.

There are a number of aspects related to the situational behavior of the autonomous vehicle’s 105, including crash mitigation strategy (CMS), evasive maneuvers, autonomous dynamic driving tasks, low communication reception, automated horn, non-compliant vehicle road user detection, scout monitoring, and oncoming traffic detection, among others.

The in-vehicle control computer 150 of the autonomous vehicle 105 described herein can address at least some of the above described problems by determining that another vehicle is violating one or more rules of the roadway based on perception data received from one or more sensors of an autonomous vehicle, tagging the other vehicle as a non-compliant driver, and modifying control of the autonomous vehicle in response to tagging the other vehicle as a non-compliant driver.

Crash Mitigation Strategy (CMS)

One important aspect involved in safely navigating an autonomous vehicle 105 is the detection and mitigation of crashes or other accidents. Thus, the in-vehicle control computer 150 can be configured to detect when the autonomous vehicle 105 has been involved in an accident, determine the severity of the accident, and based on the detection and severity, determine a course of action to minimize any further damage to the autonomous vehicle 105 and any other entities on or near the roadway.

As used herein, a car accident, also referred to as a “traffic collision,” or a “motor vehicle accident,” generally refers to the situation in which a motor vehicle strikes or collides another vehicle, a stationary object, a pedestrian, and/or an animal. While some car accidents result only in property damage, others may result in severe injuries or death.

The in-vehicle control computer 150 can be configured to detect a car accident in which the autonomous vehicle 105 is involved. For example, the in-vehicle control computer 150 can be configured to detect such an accident based on the information received from inertial sensors (e.g., when in a crash with one or more other vehicles), cameras, and/or lidars (e.g., when in a crash with vulnerable road users or animals).

In response to detecting that the autonomous vehicle 105 being involved in a car accident, the in-vehicle control computer 150 can be configured to determine the severity of the car accident. For example, the in-vehicle control computer 150 can be configured to determine that the severity of a car accident is severe in response to a detected deceleration being greater than a threshold deceleration and/or recognizing that an object the autonomous vehicle 105 has collided with is a pedestrian, cyclist, motorcycle, or other vulnerable road user (VRU). The threshold deceleration may be, for example, 4G, 5G, or 6G, however, other thresholds values are also possible without departing from aspects of this disclosure.

As used herein, a vulnerable road user may generally refer to a road user without the protection of an outside shield. Example VRUs include: pedestrians, bicyclists, skateboarder, rollerbladers, and skaters.

The in-vehicle control computer 150 can also be configured to determine that the severity of a car accident is light in response to a detected deceleration being less than the threshold deceleration and recognizing that any object the autonomous vehicle 105 has collided with is not a pedestrian, cyclist, and/or motorcycle.

The in-vehicle control computer 150 can also be configured to control the autonomous vehicle 105 to make a complete stop in response to detecting that the autonomous vehicle 105 has been involved in an accident while the autonomous vehicle 105 is moving.

The in-vehicle control computer 150 can also be configured to turn on the autonomous vehicle’s 105 hazard lights in response to detecting that the autonomous vehicle 105 has been involved in an accident.

In response to detecting that the autonomous vehicle 105 being involved in an accident, the in-vehicle control computer 150 can be configured to perform a diagnostic procedure. The in-vehicle control computer 150 can also be configured to contact the oversight system 350 in response to detecting that the autonomous vehicle 105 being involved in an accident, and in response to a request from an operator 355 at the oversight system 350, the in-vehicle control computer 150 can be configured to transmit the results of the diagnostic procedure to the operator 355. In some implementations, the diagnostic procedure can identify whether vehicle critical systems are still functioning (in particular, the vehicle critical systems involved in performing the first MRC maneuver).

In some embodiments, the in-vehicle control computer 150 can further determine that severity is light in response to determining that one or more of the following conditions is satisfied: there is no body damage to the autonomous vehicle 105, the engine is still running, the diagnostic results do not show any malfunction of autonomous vehicle 105, and/or there are no debris and/or obstacles which will restrict movement of the autonomous vehicle 105. The in-vehicle control computer 150 can be configured to control the autonomous vehicle 105 to execute the first MRC maneuver in response to determining that the severity of the accident is light.

The in-vehicle control computer 150 can also be configured to wait for a response from the operator 355 in response to determining that the severity of the accident is severe. The in-vehicle control computer 150 can control the autonomous vehicle 105 to execute the first MRC maneuver in response to receiving an instruction from the operator 355 to execute the first MRC maneuver and if the diagnostic procedures indicate that the vehicle critical systems involved in performing the first MRC maneuver are in condition to execute the first MRC maneuver.

In some embodiments, the in-vehicle control computer 150 can also be configured to remain stationary until the first MRC maneuver is triggered by the operator 355 (e.g., in the case that the in-vehicle control computer 150 has detected a severe crash) or the in-vehicle control computer 150 has determined to execute the first MRC maneuver (e.g., in the case of a light crash).

Evasive Maneuvers

Another aspect involved in safely navigating an autonomous vehicle 105 is the performance of evasive maneuvers to avoid or mitigate any accidents. The in-vehicle control computer 150 can be configured to determine whether there is a potential for any accidents and whether an accident is imminent, and determine a course of action to avoid or minimize any damage to the autonomous vehicle 105 and any other entities on or near the roadway. The in-vehicle control computer 150 can be configured to avoid colliding with any road users or obstacles whenever possible to ensure the safety of all road users.

As used herein, an evasive maneuver generally refers to a maneuver taken by the autonomous vehicle 105 to avoid or mitigate the impact of a potential or imminent accident. For example, evasive maneuvers can include swerving, braking, or a combination thereof.

As used herein, swerving generally refers to an input to the autonomous vehicle’s 105 steering to change the heading of the autonomous vehicle 105 that does not cause understeer or tipping of the trailer. As used herein, evasive steering may generally refer to an input to the autonomous vehicle’s 105 steering to change the heading of the autonomous vehicle 105 that does not cause the autonomous vehicle 105 to skid or the trailer to tip.

As used herein, braking generally refers to an input to the autonomous vehicle’s 105 braking to reduce the speed of the autonomous vehicle 105 based on the amount of speed reduction determined to execute a desired action up to the maximum braking capability of the autonomous vehicle 105. As used herein, evasive braking may generally refer to an input to the autonomous vehicle’s 105 braking to reduce the speed of the autonomous vehicle 105 using critical deceleration up to the maximum deceleration limit of the autonomous vehicle 105.

In response to executing an evasive maneuver, the in-vehicle control computer 150 can be configured to activate the autonomous vehicle’s 105 hazard lights to inform other entities on or near the roadway that the autonomous vehicle 105 is performing evasive maneuvers in response to the potential or imminent accident.

The in-vehicle control computer 150 can be configured to refrain from executing evasive maneuvers except in emergency scenarios. As used herein, an emergency scenario may generally refer to a scenario which an accident is considered to be imminent. For example, the in-vehicle control computer 150 can be configured to determine that a scenario is considered to be imminent when the autonomous vehicle 105 is on a path to collide with another entity within a predicted time to collision (TTC) that is less than a threshold time period. The threshold time period may, for example, include 0.75 s, 1 s, 1.25 s, 1.5 s, 1.75 s, 2 s, however, other threshold time periods are also possible without departing from aspects of this disclosure.

In some embodiments, the in-vehicle control computer 150 can be configured to determine that a potential collision is considered to be imminent when the in-vehicle control computer 150 predicts/calculates that the critical distance between the autonomous vehicle 105 and a road user cannot be maintained even using the upper limits of harsh deceleration. As used herein, harsh deceleration may correspond to a predetermined range of deceleration, for example, ranging from 2-4 m/s2. In some embodiments, the in-vehicle control computer 150 can predict the critical distance based on the trajectory of the autonomous vehicle 105 as well as the other road user and determine whether the critical distance between the autonomous vehicle 105 and the other road user will be broken.

In general, the in-vehicle control computer 150 can be configured to cause the autonomous vehicle 105 to stay within its current lane when executing an evasive maneuver unless evasive braking alone is not enough to prevent collision. This can help reduce the possibility of additional liability and risk that may accompany an evasive steering. For example, as used herein the autonomous vehicle 105 can execute evasive maneuvers with braking or with a combination of braking and swerving. In the case that the autonomous vehicle 105 can perform an evasive maneuver without swerving (e.g., by braking without leaving the current lane), the autonomous vehicle 105 can be configured to do so since performing an evasive maneuver without swerving may involve less risk than moving into an adjacent lane with little to no notice or signaling.

The in-vehicle control computer 150 can be configured to detect a fast reveal scenario. As used herein, a fast reveal scenario may generally refer to a scenario in which an occluded or obstructed entity or static object 422 in the autonomous vehicle’s 105 lane is suddenly revealed or otherwise becomes detectable by the autonomous vehicle 105 due to the source of occlusion 424 being suddenly removed. FIG. 4A illustrates an example visualization of a fast reveal scenario in accordance with aspects of this disclosure.

In response to detecting a fast reveal scenario, the in-vehicle control computer 150 can be configured to cause the autonomous vehicle 105 to brake up to the maximum amount of braking within safety limits to ensure the critical distance between the autonomous vehicle 105 and a target 422 of the fast reveal scenario can be maintained while in lane. As used herein, safety limits may generally refer to a maximum braking capability that the autonomous vehicle 105 can handle, which may vary based on a load in a trailer of the autonomous vehicle and/or environmental road conditions. The vehicle in-vehicle control computer 150 can be configured to determine the autonomous vehicle’s 105 braking limitations and can be configured to avoid exceeding the limits in order to prevent a potential safety critical incident. If the in-vehicle control computer 150 determines that the critical distance cannot be maintained while the autonomous vehicle 105 is braking in lane, the in-vehicle control computer 150 can be configured to cause the autonomous vehicle 105 to continue braking and swerve into an escape space if the escape space is available.

As used herein, a critical distance may generally refer to a predetermined distance from any other entity or static obstacle at all times from the closest point of the autonomous vehicle 105 to the closest point of the other entity or static obstacle. The predetermined distance may include, for example, 0.25 m, 0.5 m, 0.75 m, however, other distances are also possible. The in-vehicle control computer 150 can be configured to maintain the critical distance during all maneuvers including evasive maneuvers. Advantageously, but maintaining a critical distance from all other entities and static obstacle, the in-vehicle control computer 150 can provide a buffer that improves the safety for all road users.

As used herein, an escape space (also referred to as evasive free space) may generally refer to a space adjacent to the autonomous vehicle 105 within an expanded drivable area that is large enough for the autonomous vehicle 105 to swerve into when executing an evasive maneuver. In other words, evasive free space may generally refer to areas adjacent to the autonomous vehicle 105 within the carriageway that is large enough for the autonomous vehicle to swerve into when executing an evasive maneuver. The in-vehicle control computer 150 can be configured to determine that an escape space is available if the escape space is clear of any entities within a predetermined length of time. The predetermined length of time may include, for example, 2 s, 3 s, 4 s, 5 s, however, other lengths of time are also possible without departing from aspects of this disclosure.

As used herein, an expanded drivable area may generally refer to all road surfaces that are not in the opposite lane and without hard boundaries that can be used when conducting an evasive maneuver.

In some embodiments, the in-vehicle control computer 150 can also be configured to detect a sudden braking scenario. As used herein, a sudden braking scenario may generally refer to a scenario in which the entity in front of the autonomous vehicle 105 and in the same lane brakes suddenly with a deceleration of more than a predetermined amount of deceleration. The predetermined amount of deceleration can include, for example, 2.5 m/s2, 3 m/s2, 4 m/s2, 5 m/s2, 6 m/s2, although other deceleration amounts are also possible. FIGS. 4B-4C illustrate example visualizations of sudden braking scenarios in accordance with aspects of this disclosure.

In response to detecting a sudden braking scenario, the in-vehicle control computer 150 can be configured to cause the autonomous vehicle 105 to brake up to the maximum amount of braking within safety limits to ensure the critical distance between the autonomous vehicle 105 and the target of the sudden braking scenario can be maintained while in lane. If the in-vehicle control computer 150 determines that the critical distance cannot be maintained from another vehicle 426 or entity while the autonomous vehicle 105 is braking in lane, the in-vehicle control computer 150 can be configured to cause the autonomous vehicle 105 to continue braking and swerve into an escape space if the escape space is available.

Another scenario which can be detected by the in-vehicle control computer 150 is a lateral intrusion scenario. As used herein, a lateral intrusion scenario may generally refer to a scenario in which an entity 426 that is travelling in a parallel lane or direction is rapidly intruding into the autonomous vehicle’s 105 lane and the in-vehicle control computer 150 predicts that the entity 426 will collide with a side of the autonomous vehicle 105. FIG. 4D illustrates an example visualization of a lateral intrusion scenario in accordance with aspects of this disclosure.

In response to detecting a lateral intrusion scenario, the in-vehicle control computer 150 can be configured to cause the autonomous vehicle 105 to swerve if an escape space on the opposite side of the potential collision side is available to maintain the critical distance from the entity 426. After swerving, the in-vehicle control computer 150 can be configured to cause the autonomous vehicle 105 to slow down to avoid staying parallel to the intruding vehicle. If an escape route is not available, the in-vehicle control computer 150 can be configured to cause the autonomous vehicle 105 to only use evasive braking and slow the autonomous vehicle 105 down to avoid the intruding vehicle.

The in-vehicle control computer 150 can also be configured to detect a cross path scenario. As used herein, a cross path scenario may generally refer to a scenario in which an entity 426 travelling in a non-parallel lane or direction is predicted to cross with the autonomous vehicle’s 105 path. FIG. 4E illustrates an example visualization of a cross path scenario in accordance with aspects of this disclosure.

In response to detecting a cross path scenario, the in-vehicle control computer 150 can be configured to cause the autonomous vehicle 105 to brake up to the maximum amount of braking within safety limits to ensure the critical distance between the autonomous vehicle 105 and the target 426 of the cross path scenario can be maintained while in lane. If the in-vehicle control computer 150 determines that the critical distance cannot be maintained while the autonomous vehicle 105 is braking in lane, the in-vehicle control computer 150 can be configured to cause the autonomous vehicle 105 to continue braking and swerve into an escape space if the escape space is available.

Another scenario which can be detected by the in-vehicle control computer 150 is an oncoming scenario. As used herein, an oncoming scenario may generally refer to a scenario in which an entity 426 travelling in a parallel lane but in an opposite direction to the autonomous vehicle 105 is predicted to intersect with the autonomous vehicle’s 105 path. FIG. 4F illustrates an example visualization of an oncoming scenario in accordance with aspects of this disclosure.

In response to detecting an oncoming scenario, the in-vehicle control computer 150 can be configured to cause the autonomous vehicle 105 to brake up to the maximum amount of braking within safety limits and swerve away from the oncoming entity 426. In some embodiment, the autonomous vehicle 105 can swerve into the escape space (also referred to as an “out”) if the escape space is available. An escape space can include unoccupied areas adjacent to the autonomous vehicle 105 including in front, behind, or to either side of the autonomous vehicle 105 or a combination thereof. The in-vehicle control computer 150 can periodically (e.g., continuously in some embodiment) determine whether the escape spaces are available for the autonomous vehicle 105 to move into. If the escape space is unavailable, the in-vehicle control computer 150 can be configured to cause the autonomous vehicle 105 to use only evasive braking.

The in-vehicle control computer 150 can further be configured to detect a cut-in scenario. As used herein, a cut-in scenario may generally refer to a scenario in which an entity 426 travelling in a parallel lane or direction as the autonomous vehicle 105 is predicted to cut into the autonomous vehicle’s 105 path. FIG. 4G illustrates an example visualization of a cut-in scenario in accordance with aspects of this disclosure.

In response to detecting a cut-in scenario, the in-vehicle control computer 150 can be configured to cause the autonomous vehicle 105 to brake up to the maximum amount of braking within safety limits to ensure the critical distance between the autonomous vehicle 105 and the target 426 of the cut-in scenario can be maintained while in lane. If the critical distance cannot be maintained while the autonomous vehicle 105 is braking in lane, the autonomous vehicle 105 may continue braking and swerve away from the direction of the cut in and direct the autonomous vehicle 105 into the escape space if the escape space is available. If the escape space is unavailable, the in-vehicle control computer 150 can be configured to cause the autonomous vehicle 105 to use only evasive braking.

In some embodiments, the in-vehicle control computer 150 can also be configured to predict whether an emergency scenario has a probability that is greater than a threshold probability based on perception data received from one or more of the sensors of the vehicle sensor subsystems 144. In particular, the in-vehicle control computer 150 can use perception data related to entities in the same lane in front of the autonomous vehicle 105 as well as entities in adjacent lanes and entities in cross paths when the autonomous vehicle 105 is at or near an intersection.

In some implementations, when considering whether to perform any type of evasive maneuver, the in-vehicle control computer 150 can consider the ranges of possible motion (e.g., predicted motion) for the types of entities in the immediate surroundings of the autonomous vehicle 105. For example, if an entity is predicted to enter an escape space, the in-vehicle control computer 150 can determine that the safe space is not available for an evasive maneuver.

The in-vehicle control computer 150 can also be configured to select and monitor the closest entities (e.g., entities within a predetermined distance) within the autonomous vehicle’s 105 predicted path of travel as well as entities with a predicted path that crosses the autonomous vehicle’s 105 predicted path as potential targets for evasive maneuvers. Any monitored entity that meets the criteria for performing an evasive maneuver in response to a predefined scenario may trigger the in-vehicle control computer 150 to take actions consistent with the determined scenario.

When the in-vehicle control computer 150 has determined to perform an evasive maneuver, the in-vehicle control computer 150 can commit the target of the evasive maneuver to memory until the autonomous vehicle 105 has completely come to a stop and/or if the emergency scenario is no longer valid.

After determining that the autonomous vehicle 105 has executed an evasive maneuver and has successfully avoided an accident, the in-vehicle control computer 150 can be configured to return the autonomous vehicle 105 to normal operations and the autonomous vehicle’s 105 previous lane of travel prior to the evasive maneuver provided the intended lane and trajectory is clear of other entities and/or obstacles.

The in-vehicle control computer 150 can be configured to determine if the autonomous vehicle 105 is in an accident and a collision has occurred. For example, the in-vehicle control computer 150 can use the motion of the autonomous vehicle 105 and the distance of the autonomous vehicle 105 to other entities to determine if the autonomous vehicle 105 is in an accident. After the in-vehicle control computer 150 has determined that the autonomous vehicle 105 is in an accident and the autonomous vehicle 105 has come to a stop, the in-vehicle control computer 150 can be configured to continue holding the brakes for an extra define length of time (e.g., 5 s) to prevent the possibility of the autonomous vehicle 105 being displaced due to secondary impact(s).

Autonomous Dynamic Driving Tasks

The in-vehicle control computer 150 can be configured to perform real-time operational and tactical functions which can be termed dynamic driving tasks. As used herein, dynamic driving tasks (DDT) may generally refer to all of the real-time operational and tactical functions required to operate an autonomous vehicle 105 in on-road traffic. DDT may differ from driving because DDT can include tactile and functional effort, but can exclude strategic effort. DDT may not even involve the autonomous vehicle 105 being in motion.

As used herein, object and event detection and response (OEDR) may generally refer to the subtasks of the DDT that include monitoring the driving environment (detecting, recognizing, and classifying objects and events and preparing to respond as needed) and executing an appropriate response to such objects and events.

The in-vehicle control computer 150 can be configured to detect and classify all on-road and off-road objects, as well as the environmental events that impact the driving tasks. The in-vehicle control computer 150 can be configured to detect system failures that impact the ability to complete driving tasks.

The in-vehicle control computer 150 can be configured to detect all on-road stationary and dynamic objects that impact the driving tasks. For example, the in-vehicle control computer 150 can be configured to detect the following static on-road objects: road and lane markings, construction signs, obstructions, and other on-road static objects. The in-vehicle control computer 150 can also be configured to detect the following dynamic on-road objects: 4 wheelers vehicles, 2 wheelers (e.g., cyclists, motorcycles), pedestrians, dynamic traffic signs, and other on-road dynamic objects (e.g., animals, unknown objects).

The in-vehicle control computer 150 can be configured to detect all off-road stationary and dynamic objects that impact the driving tasks. For example, the in-vehicle control computer 150 can be configured to detect the following static off-road objects: road and traffic signs, traffic lights, curbs, construction signs, vehicles (parked/stopped), pedestrians, and other off-road static objects. The in-vehicle control computer 150 can be configured to detect the following dynamic off-road objects: vehicles (stopping in curbside or merging into the road), pedestrians, and other off-road dynamic objects.

The in-vehicle control computer 150 can be configured to detect environmental events in order to respond to them autonomously and safely. For example, environmental events can include weather conditions and road conditions (e.g., accident areas).

The in-vehicle control computer 150 can be configured to adjust the autonomous vehicle’s 105 lateral position by adjusting the steering angle. The in-vehicle control computer 150 can be configured to follow the limitations of steering (e.g., maximum turning angle, maximum turn rate). Different maneuvers may translate to a set of lateral control tasks.

The in-vehicle control computer 150 can be configured to adjust the autonomous vehicle’s 105 longitudinal position by accelerating and decelerating to a speed that is required by DDT. The in-vehicle control computer 150 can be configured to accelerate the autonomous vehicle 105 to a desired speed safely with a predetermined maximum rate. The in-vehicle control computer 150 can be configured to decelerate the autonomous vehicle 105 to a desired speed safely with a predetermined maximum rate. The in-vehicle control computer 150 can be configured to control the autonomous vehicle 105 to complete a desired STOP maneuver (e.g., comfort stop, safe stop, emergency stop). Different maneuvers may translate to a set of longitudinal control tasks.

The in-vehicle control computer 150 can be configured to plan maneuvers that are required to navigate autonomously and safely in ODD. The in-vehicle control computer 150 can be configured to complete DDT that are required for all the plan maneuvers.

Example operational and tactical maneuvers can include: parking, maintaining speed, target car following, lane centering, lane changing, passing (including aborting passing), enhancing conspicuity, obstacle avoidance, low-speed merge, high-speed merge, navigating on/off ramps, yielding (e.g., right-of-way decisions), following driving laws, navigating roundabouts, navigating intersections, navigating crosswalks, navigating work zones, turning, U-Turns, transitioning to MRC maneuvers, and route planning.

Low Communication Reception

Since the autonomous vehicle 105 may communicate with the oversight system 350 during navigation, it can be beneficial to determine the reliability of the autonomous vehicle’s 105 wireless connection. As used herein, wireless communication reliability may generally refer to the reception rate of the autonomous vehicle’s 105 wireless transceiver (e.g., the network communications subsystem 178). A low reception rate may be the general case defined by a packet drop ratio that is higher than a threshold value.

A reliability unit can be measured using a metric in the interval of [0,1]. Reliability units can include a probabilistic model describing the behavior of losing communication. In this way, the in-vehicle control computer 150 can predict the loss of communication. The metric can be configured to measure quantitative characteristics or variables.

The in-vehicle control computer 150 can be configured to determine the reliability of the wireless communication using the reception rate experienced while driving during the last predetermined distance. The predetermined distance can include, for example, 400 m, 500 m, 600 m, although other distances are also possible. The in-vehicle control computer 150 can determine the reliability of the wireless communication based on the average of reception rate.

The in-vehicle control computer 150 can detect the regaining of wireless communication using the reliability of wireless communication threshold of a predetermined number of reliability units. In some embodiments, the predetermined number of reliability units can include, for example, 0.3, 0.4, or 0.5 reliability units, although other values are possible without departing from aspects of this disclosure.

In response to determining that the reliability of wireless communication is less than a threshold value, the in-vehicle control computer 150 can continue to drive on the current route using an onboard localization system for a predetermined distance. If the in-vehicle control computer 150 does not regain wireless communication within the predetermined distance, the in-vehicle control computer 150 can activate the first MRC maneuver. In some embodiments, the threshold value can include, for example, 0.5, 0.1, 0.2 reliability units and the predetermined distance can include, for example, 1 mile, 1.5 miles, 2 miles, 2.5 miles, although other values are also possible. The reliability of wireless communication can be normalized in the interval of [0,1] reliability units.

In response to determining that the reliability of wireless communication is lower than a threshold value, the in-vehicle control computer 150 can prioritize data to be sent to the oversight system 350 and continue the current mission to the destination. The threshold value can be, for example, 0.5, 0.6, 0.7, 0.8 reliability units, although other values are also possible.

In response to determining that the reliability of wireless communication is lower than a threshold value, the in-vehicle control computer 150 can reduce the update rate of data to be sent to the oversight system 350 and continue the current mission to the destination. The threshold value can be, for example, 0.3, 0.4, 0.5 reliability units, although other values are also possible. When the in-vehicle control computer 150 reduces data sent to the oversight system 350, communication can be established when the reliability of wireless communication is lower than a threshold value.

The in-vehicle control computer 150 can also be configured to determine whether the map indicates that a tunnel is on the current route of the autonomous vehicle 105 within a predetermined threshold distance ahead of the autonomous vehicle 105. In response to determining that a tunnel is within the predetermined threshold distance, the in-vehicle control computer 150 can be configured to plan to rely more on the onboard localization system to ensure the autonomous vehicle 105 is moving in the right direction and when the autonomous vehicle 105 comes out of tunnel, the in-vehicle control computer 150 can resume normal usage of wireless communication for localization purposes. The predetermined threshold distance can include, for example, 75 m, in the next 100 m, in the next 150 m, although other distances are also possible without departing from aspects of this disclosure. The in-vehicle control computer 150 can be configured to avoid activating the first MRC maneuver while in the tunnel and while there is no wireless communication available.

The in-vehicle control computer 150 can also be configured to cause the autonomous vehicle 105 to continue the current mission using an onboard localization system in response to determining that the map indicates that the current route includes a road segment with low reception. In response to detecting the regaining of communication, the in-vehicle control computer 150 can inform the oversight system 350 about the current location of the autonomous vehicle 105.

Automated Horn

The autonomous vehicle 105 can be equipped with a horn that can be used to communicate with other entities on or near the roadway, particularly when such communication can be used to prevent or reduce the severity of an accident. The autonomous vehicle 105 may use a number of different inputs in determining whether to actuate the horn and what type of horn to activate.

The autonomous vehicle 105 can be configured to activate at least two different types of horn activation: short and long. In some implementations, a short horn may be defined as an activated horn for a first predetermined period of time (e.g., 0.25 sec, 0.5 sec, 0.75 sec) and a long horn may be defined as an activated horn for a second predetermined period of time (e.g., 0.5 sec, 1 sec, 1.5 sec).

Prior to actuating the horn, the autonomous vehicle 105 may determine whether the autonomous vehicle 105 is currently located in a zone where horn activation is prohibited. In some embodiments, the autonomous vehicle 105 can store a predetermined map which can include zones where activating the horn is prohibited. Thus, prior to activating the horn the autonomous vehicle 105 can determine whether its current position is outside of any zones where activating the horn is prohibited. Depending on local regulations, horn activation may be prohibited on local streets of residential areas between the hours of 11.30 pm and 7.00 am, hospitals, and/or in school zones. In some embodiments, the autonomous vehicle 105 can also determine whether the autonomous vehicle 105 is located in a zone where horn use is prohibited using one of more sensors. For example, the autonomous vehicle 105 can determine that it is located in a school zone based on detecting a sign indicating the presence of a school zone.

Another aspect in determining when to activate the horn of the autonomous vehicle 105 includes detecting other entities (e.g., NPCs) on or near the roadway. For example, the autonomous vehicle 105 can detect moving entities and attributes associated with the detected entities at a predetermined distance away from the autonomous vehicle 105 (e.g., 100 m, 150 m, 175 m, 200 m). The autonomous vehicle 105 can be configured to detect one or more of the following attributes associated with each detected moving entity: position, speed, direction of movement of the moving entity, acceleration, etc.

One situation in which the autonomous vehicle 105 can activate the long horn is when the safety of a moving entity is at risk. For example, when the autonomous vehicle 105 detects that an oncoming vehicle has crossed the lane divider and a lane bias level of the oncoming vehicle is insufficient to reach a lateral gap greater than a predetermined threshold distance (e.g., 0.75 m, 1 m, 1.25 m, 1.5 m), the autonomous vehicle 105 may activate the long horn once. Other situations under which the autonomous vehicle 105 may activate the long horn in response to detecting a potential risk to the safety of a moving entity and the lateral gap are described in the Oncoming Traffic Detection section.

One situation in which the autonomous vehicle 105 can activate the short horn is when certain types of stationary entities are detected. For example, when the autonomous vehicle 105 detects a vehicle (except for emergency vehicles and/or vehicles with hazard lights on) is stopped for a predetermined length of time (e.g., 8 sec, 10 sec, 12 sec, 15 sec) with no vehicle in front of the autonomous vehicle 105 and a lane change is not possible, the autonomous vehicle 105 can activate the short horn once. Certain local laws and/or regulations may prohibit sounding the horn in response to a stationary entity unless necessary to avoid a collision. Thus, the autonomous vehicle 105 may only activate the short horn in response to detecting a stationary vehicle as described above when the autonomous vehicle 105 determines that activating the horn can avoid a potential collision.

Another situation in which the autonomous vehicle 105 can activate the long horn is when the autonomous vehicle 105 predicts that a reversing vehicle will collide with the autonomous vehicle 105 and the predicted TTC is less than or equal to a threshold amount of time (e.g., about 2 sec, about 3 sec, about 4 sec, about 5 sec). The autonomous vehicle 105 may activate the long horn once in response to the above conditions being met.

Another situation in which the autonomous vehicle 105 can activate the short horn is when a road corner/curve is detected and the current visibility is less than a predetermined distance (e.g., 150 feet, 200 feet, 225 feet, 250 feet). When these conditions are met, the autonomous vehicle 105 can activate the short horn once before crossing corner/curve to warn oncoming vehicles or other entities.

Yet another situation in which the autonomous vehicle 105 can activate the short horn is when a “non-compliant driver-lane crossing vehicle” and/or a “non-compliant driver-too Close for Comfort” are detected. The autonomous vehicle 105 may activate the short horn once when these conditions are met.

Non-Compliant Driver Detection

One aspect to the safe autonomous navigation of an autonomous vehicle 105 includes the detection and tracking of non-compliant drivers (also referred to as non-compliant vehicle road users).

As used herein, a non-compliant driver may generally refer to a vehicle road user that is not complying with one or more traffic rules. The in-vehicle control computer 150 can be configured to detect, classify, and/or respond to non-compliant drivers based on the particular rule(s) being violated by the non-compliant driver. For example, the in-vehicle control computer 150 can be configured to classify non-compliant drivers into one or more of the following classifications: lane crossing, erratic, speeding, oscillating, intersection, and/or static.

The in-vehicle control computer 150 can be configured to detect lane crossing non-compliant drivers. As used herein, a lane crossing non-compliant driver may generally refer to as a non-compliant driver who illegally crosses a lane line into the autonomous vehicle’s 105 lane or a lane adjacent to the autonomous vehicle’s 105 lane. Lane crossing non-compliant drivers may present the additional risk of becoming a critical distance cut in vehicle, which can be a safety hazard for the autonomous vehicle 105.

In some embodiments, the in-vehicle control computer 150 can be configured to detect a lane crossing non-compliant driver that crosses any lane boundary (including the mirrors of the non-compliant driver’s vehicle), without changing lanes and/or without the usage of turn signals, while driving in front of and in the same lane as the autonomous vehicle 105. The in-vehicle control computer 150 can be configured to detect a lane crossing non-compliant driver that crosses the lane boundary (including mirrors of the non-compliant driver’s vehicle) on the side closest to the autonomous vehicle 105 without changing lanes while the non-compliant driver is driving in a lane adjacent to the autonomous vehicle’s 105 lane-of-travel.

The in-vehicle control computer 150 can be configured to detect erratic non-compliant drivers. As used herein, an erratic non-compliant driver may generally refer to a non-compliant driver who breaks traffic laws in a variety of ways. Erratic non-compliant drivers may operate vehicles to make aggressive maneuvers and the in-vehicle control computer 150 can be configured to avoid non-compliant vehicles as much as possible for the safety of the autonomous vehicle 105 and other road users. For example, an erratic non-compliant driver may break traffic laws in one or more of the following ways: a vehicle that is driving the wrong way, opposite to the flow of traffic, a vehicle that is driving outside of the drivable lanes or on a gore area, and/or a vehicle that cuts across multiple lanes of traffic without utilizing turn signal. As used herein, a gore area generally refers to an area that is in the emergency lane area and is often found in between a lane split or highway exit for example. Please see the Map Taxonomy Section for additional details regarding gore areas.

The in-vehicle control computer 150 can also be configured to detect speeding non-compliant drivers. As used herein, a speeding non-compliant driver may generally refer to a driver who is driving significantly faster than the speed limit of the roadway the vehicle is driving on. In some embodiments, the in-vehicle control computer 150 can label a vehicle as a speeding non-compliant driver in response to detecting that the vehicle is driving at least 25 mph over the speed limit, although other values are also possible. Speeding non-compliant drivers may operate vehicles that drive dangerously fast and are a safety hazard for other road users.

The in-vehicle control computer 150 can further be configured to detect intersection non-compliant drivers. As used herein, an intersection non-compliant driver may generally refer to a vehicle that breaks traffic rule(s) in or near an intersection. Intersection non-compliant drivers are vehicles that break traffic rule(s) at an intersection and in most cases, the in-vehicle control computer 150 can be configured to yield to intersection non-compliant drivers before proceeding through the intersection. In some embodiments, the in-vehicle control computer 150 can be configured to label a vehicle as an intersection non-compliant driver in response to detecting that the vehicle has broken one or more of the following rules: proceeding through the intersection without right-of-way, executing an illegal U-turn, lane changing inside the intersection, and/or turning from Straight Lane.

In response to detecting a non-compliant driver, the in-vehicle control computer 150 can be configured to label, tag, or otherwise remember the non-compliant driver for a predetermined length of time after the non-compliant driver has committed a non-compliant maneuver. The predetermined length of time may include, for example 10 s, although other lengths of time are also possible. Because a non-compliant driver may be at risk of performing sequential non-compliant maneuvers, by labeling and remembering the non-compliant driver for the predetermined length of time, the in-vehicle control computer 150 can avoid the non-compliant driver if possible. In some embodiments, the in-vehicle control computer 150 can be configured to retain tags of non-compliant drivers for the predetermined length of time after the non-compliant maneuver was performed.

The in-vehicle control computer 150 can be configured to reduce or minimize the amount of time spent driving parallel to a non-compliant driver. Driving parallel to a non-compliant driver may present a safety risk, and thus, the in-vehicle control computer 150 can be configured to avoid driving parallel to non-compliant drivers. The in-vehicle control computer 150 can be configured to break from driving parallel to a non-compliant driver by passing the non-compliant driver or braking.

In one example scenario, the autonomous vehicle 105 can be driving on a roadway and detects a non-compliant vehicle. The in-vehicle control computer 150 can detect the non-compliant vehicle becoming parallel to the autonomous vehicle 105 and assess options to brake when parallel with the non-compliant driver. The in-vehicle control computer 150 can then control the autonomous vehicle 105 to break from driving parallel with the non-compliant vehicle based on a selected one of the options. FIG. 4H illustrates an example visualization of a vehicle driven by a non-compliant driver 428 (also referred to simply as a non-compliant driver) parallel to the autonomous vehicle 105 in accordance with aspects of this disclosure.

The in-vehicle control computer 150 can be configured to avoid lane changing into the lane of a speeding non-compliant driver 428 lane until after the non-compliant driver 428 has passed the autonomous vehicle 105 in response to detecting the non-compliant driver 428. If the autonomous vehicle 105 were to cut in front of a speeding non-compliant driver, it could risk a collision and thus, the in-vehicle control computer 150 can be configured to avoid cutting in front of non-compliant drivers 428, and in particular speeding non-compliant drivers 428, if possible.

In one example scenario, the in-vehicle control computer 150 can detect a speeding non-compliant driver 428 in response to detecting that a vehicle is moving at least 25 mph over the speed limit. The in-vehicle control computer 150 can be configured to let the detected speeding non-compliant driver 428 pass before lane changing. If the in-vehicle control computer 150 intends to make lane change after detecting the speeding non-compliant deriver 428, the in-vehicle control computer 150 can evaluate its target lane with respect to the speeding non-compliant driver 428. In response to the target lane being the same for the approaching speeding non-compliant driver 428, the in-vehicle control computer 150 can delay the intended lane change until the speeding non-compliant driver 428 has passed, unless the lane change is critical. The in-vehicle control computer 150 can then perform the lane change after the speeding non-compliant driver 428 has passed the autonomous vehicle 105. FIG. 4I illustrates an example visualization of a speeding non-compliant vehicle in accordance with aspects of this disclosure.

The in-vehicle control computer 150 can be configured to avoid driving in a lane adjacent to an oscillating non-compliant driver 428 if a projected trajectory of the autonomous vehicle 105 will be parallel with the oscillating non-compliant driver 428. Oscillating non-compliant drivers 428 may be at risk of entering the autonomous vehicle’s 105 minimum critical distance. Thus, the autonomous vehicle 105 avoids driving in parallel to oscillating non-compliant drivers 428 to maintain the minimum critical distance.

In one example scenario, the in-vehicle control computer 150 may detect an oscillating non-compliant driver 428 in a vehicle that is swerving between both of its lane lines while attempting to keep in the lane. The in-vehicle control computer 150 can continue on route while avoiding the detected non-compliant driver 428. The in-vehicle control computer 150 can also project the trajectory of the autonomous vehicle 105 and predict the trajectory of the oscillating non-compliant driver 428. In response to predicting parallel interaction with the oscillating non-compliant driver 428, the in-vehicle control computer 150 can control the autonomous vehicle 105 to execute a lane change to avoid being parallel with the oscillating non-compliant driver 428. If the in-vehicle control computer 150 predicts no parallel interaction with the oscillating non-compliant driver 428, the in-vehicle control computer 150 can control the autonomous vehicle 105 to proceed on route without instructing any changes to the driving parameters. FIG. 4J illustrates an example visualization of an oscillating non-compliant vehicle in accordance with aspects of this disclosure.

The in-vehicle control computer 150 can be configured to yield right-of-way to an intersection non-compliant driver 428. In some embodiments, in response to detecting an intersection non-compliant driver 428 in or near an intersection that the autonomous vehicle 105 plans to proceed through, the in-vehicle control computer 150 can be configured to wait to proceed through the intersection until the intersection non-compliant driver 428 has cleared the autonomous vehicle’s 105 projected trajectory.

In an example scenario, the in-vehicle control computer 150 can be configured to detect an intersection non-compliant driver 428 that proceeds into or through an intersection when the vehicle does not have the right-of-way. In response, the in-vehicle control computer 150 can be configured to yield to the intersection non-compliant driver 428 and then proceed through intersection after the non-compliant driver 428 has cleared the autonomous vehicle’s 105 planned trajectory. If the in-vehicle control computer 150 detects that the intersection non-compliant driver 428 comes to stop inside intersection and the in-vehicle control computer 150 confirms that the intersection non-compliant driver 428 does not intersect the autonomous vehicle’s 105 planned trajectory, the in-vehicle control computer 150 can control the autonomous vehicle 105 to proceeds through the intersection without waiting for the non-compliant vehicle to clear the intersection. FIG. 4K illustrates an example visualization of an intersection non-compliant vehicle in accordance with aspects of this disclosure.

The in-vehicle control computer 150 can further be configured to avoid changing lanes towards any tagged non-compliant drivers 428 unless required to continue on route. The in-vehicle control computer 150 can also be configured to maintain a recommended lateral distance at all times to any non-compliant drivers 428. This is advantageous because non-compliant drivers 428 may be unpredictable and a safety risk.

In some embodiments, the in-vehicle control computer 150 can be configured to detect a static vehicle in the road at a predetermined distance. The predetermined distance can include, for example, 200 m, 222 m, 250 m, 300 m, although other distances are also possible. The in-vehicle control computer 150 can label any detected static vehicle and inform the oversight system 350 of the detected static vehicle position in the road.

In response to detecting a static vehicle in front of the autonomous vehicle 105, the in-vehicle control computer 150 can be configured to consider a critical safety lane change intention and perform a lane change. If, in response to detecting the static vehicle in front of the autonomous vehicle 105, the in-vehicle control computer 150 determines that a lane change is not possible and/or a lane bias level is insufficient to reach a predetermined lateral gap (e.g., greater than or equal to 1 m, 2 m, 3 m) with the static vehicle, the in-vehicle control computer 150 can be configured to control the autonomous vehicle 105 to stop on a shoulder or emergency lane and/or pull over to the rightmost lane. The in-vehicle control computer 150 can also inform the oversight system 350 and activate the hazard lights. The predetermined lateral gap can include, for example, 1 m, 2 m, 3 m, although other gaps are also possible without departing from aspects of this disclosure.

The in-vehicle control computer 150 can also be configured to detect the speed of vehicles that are located in front, to the right, and to the left side of the autonomous vehicle 105. In response to the detected speed of one of the vehicles being greater than the speed limit indicated by map or traffic signs of the road, the in-vehicle control computer 150 can be configured to classify the vehicle as a dynamic non-compliant driver 428 and inform the oversight system 350 of the position of the dynamic non-compliant driver 428. The in-vehicle control computer 150 can also be configured to determine that the speed of the dynamic non-compliant driver 428 in front of the autonomous vehicle 105 is less than the speed of the autonomous vehicle 105, and in response, dynamically slow down the speed of the autonomous vehicle 105 to maintain a higher than normal following distance of a predetermined amount. The predetermined amount may include, for example, 8%, 10%, 12% higher than normal following distance, although other values are also possible.

The in-vehicle control computer 150 can further be configured to detect the direction of movement of vehicles that are detected in front, to the right, or to the left side of the autonomous vehicle 105. In response to the detected direction of movement being opposite to the expected traffic flow indicated by map or by traffic signs of the road, the in-vehicle control computer 150 can classify the vehicle as a dynamic non-compliant driver 428 and inform the oversight system 350 of the location, direction, and speed of the dynamic non-compliant driver 428. In response to detecting an oncoming dynamic non-compliant driver 428 in the same lane as the autonomous vehicle 105 and the direction of movement being towards the autonomous vehicle 105, the in-vehicle control computer 150 can consider a critical safety lane change intention and perform a lane change if possible.

Scout Monitoring

Because an autonomous vehicle 105 can function without any operator on board, the autonomous vehicle 105 may be more vulnerable to possible hijacking than other vehicles. Thus, the in-vehicle control computer 150 can be configured to perform scout monitoring, in which the in-vehicle control computer 150 monitors for entities attempting to determine the autonomous vehicle’s 105 load for possible hijacking. As used herein, scouting may generally refer to an unknown entity conducting an assessment to determine the autonomous vehicle’s 105 load for possible hijacking.

In some embodiments, the in-vehicle control computer 150 can be configured to perform static scout monitoring including monitoring for other vehicles attempting to determine the autonomous vehicle’s 105 load for possible hijacking while the autonomous vehicle 105 is parked or static. For example, the in-vehicle control computer 150 can detect a scouting event in response to one or more of the following conditions being met: the autonomous vehicle 105 is parked, an unknown vehicle with a person inside or a pedestrian is within a first predetermined distance of the autonomous vehicle 105, measured from the autonomous vehicle’s 105 centroid to the unknown vehicle or pedestrian’s nearest point, and the vehicle or pedestrian remains within a second predetermined threshold distance of the autonomous vehicle 105 for at least a predetermined length of time consecutively. The first predetermined distance can include, for example, 8 m, 10 m, 12 m, 15 m, the second predetermined threshold distance can include, for example, 8 m, 10 m, 12 m, 15 m, and the predetermined length of time can include, for example, 10 min, 15 min, 20 min, although other values are also possible.

The in-vehicle control computer 150 can detect a scouting event in response to one or more of the following conditions being met: the autonomous vehicle 105 is within the perimeter of a shipping center, an unknown vehicle is within the perimeter of the shipping center that the autonomous vehicle 105 is in, and the unknown vehicle is unauthorized and unmarked.

The in-vehicle control computer 150 can also detect a scouting event in response to one or more of the following conditions being met: the autonomous vehicle 105 is within the perimeter of an autonomous freight network (AFN) terminal, an unknown vehicle is within the perimeter of the AFN terminal that the autonomous vehicle 105 is in, and the unknown vehicle is unauthorized and unmarked.

As used herein, dynamic scout monitoring can generally refer to the activity of monitoring for other vehicles attempting to determine the autonomous vehicle’s 105 load for possible hijacking while the autonomous vehicle 105 is moving or dynamic.

In some embodiments, the in-vehicle control computer 150 can detect a scouting event in response to a vehicle being within a predetermined distance of the autonomous vehicle 105 and the vehicle has a person on its exterior. The predetermined distance can include, for example, 10 m, 12 m, 15 m, 17 m, 20 m, although other distances are also possible without departing from aspects of this disclosure.

The in-vehicle control computer 150 can detect a scouting event in response to one or more of the following conditions being met: at least a predetermined number of vehicles (e.g., 3 or more, 4 or more, 5 or more NPCs) remain parallel, in front of, and/or behind the autonomous vehicle 105 within a predetermined distance (e.g., 15 m, 17 m, 20 m, 22 m, 25 m) of the autonomous vehicle’s 105 centroid for more than a predetermined length of time (e.g., 4 min, 5 min, 6 min) consecutively, the autonomous vehicle’s 105 velocity is greater than a threshold velocity (e.g., 25 mph, 30 mph, 35 mph), and all of the vehicles in proximity of the autonomous vehicle 105 maintain a relative velocity within a predetermined relative velocity (e.g., 4 mph, 5 mph, 6 mph) of the autonomous vehicle 105 for the duration of the period. The predetermined number of vehicles can include, for example, 3 or more, 4 or more, 5 or more vehicles, the predetermined distance can include, for example, 15 m, 17 m, 20 m, 22 m, 25 m, the predetermined length of time can include, for example, 4 min, 5 min, 6 min, the threshold velocity can include, for example, 25 mph, 30 mph, 35 mph, and the predetermined relative velocity can include, for example, 4 mph, 5 mph, 6 mph, although other values are also possible.

The in-vehicle control computer 150 can detect a scouting event in response to the autonomous vehicle’s 105 connection to the oversight system 350 being interrupted or tampered due to an unknown intentional source.

In response to detecting any potential scout monitoring actively occurring, the in-vehicle control computer 150 can be configured to contact the oversight system 350 with high priority, at risk alerts.

Oncoming Traffic Detection

Another aspect to the safe navigation of the autonomous vehicle 105 includes detecting and responding to oncoming traffic. For example, the autonomous vehicle 105 can be configured to maintain a lateral gap with all oncoming traffic. As used herein, a lateral gap may generally refer to a minimum lateral distance between the autonomous vehicle 105 and any oncoming vehicles 430 or other entities. For example, the minimum lateral distance may be the lateral distance between the closest points on the autonomous vehicle 105 and the oncoming vehicle 430. In some embodiments, the in-vehicle control computer 150 can be configured to consider the side mirrors in measuring the lateral gap between the autonomous vehicle 105 and the oncoming vehicle 430. FIG. 4L illustrates an example visualization of a bumper-to-bumper gap and a lateral gap in accordance with aspects of this disclosure.

The in-vehicle control computer 150 can be configured to measure a bumper-to-bumper gap between the front bumper of the autonomous vehicle 105 and the front bumper of the oncoming vehicle 430. In some embodiments, the in-vehicle control computer 150 can be configured to continuously monitor oncoming vehicles that have a bumper-to-bumper distance greater than the distance necessary to stop with a predetermined deceleration. The predetermined deceleration may include, for example, -4 m/s2, -5 m/s², -6 m/s2, although other values are possible. The predetermined deceleration may depend on environmental factors such as the road traction.

In one example scenario, the autonomous vehicle 105 and an oncoming vehicle 430 can be travelling on a two-way road at 80 km/h. The time necessary to stop with a deceleration of 5 m/s² is about 5 s, with a distance to stop around 50 m, and the distance traveled by the oncoming vehicle 430 of around 100 m. In this scenario, the field of view may be greater than about 150 m.

In some embodiments, the in-vehicle control computer 150 can be configured to estimate the lateral gap and bumper-to-bumper gap for oncoming vehicles. The in-vehicle control computer 150 can also be configured to determine a relative longitudinal speed between the autonomous vehicle 105 and the oncoming vehicle to compute TTC with a derivative of the bumper-to-bumper gap.

The in-vehicle control computer 150 can also be configured to classify an oncoming vehicle 430 as an oncoming, non-critical safety vehicle in response to determining that the predicted lateral gap of the oncoming vehicle 430 at TTC is less than a predetermined upper threshold distance and greater than a predetermined lower threshold distance. The in-vehicle control computer 150 can be configured to predict the lateral gap of an oncoming vehicle 430 at the time when bumper to bumper gap equals 0 (e.g., the TTC is equal to 0).

The in-vehicle control computer 150 can also be configured to classify an oncoming vehicle 430 as an oncoming critical safety vehicle in response to predicting the lateral gap of the oncoming vehicle 430 at TTC is less than the predetermined lower threshold distance. In response to detecting an oncoming critical safety vehicle, the in-vehicle control computer 150 can be configured to consider a critical safety lane change intention and perform the lane change if possible. In some embodiments, the in-vehicle control computer 150 can be configured to prioritize the following lateral maneuvers to increase or maximize the lateral gap with oncoming vehicle 430 (from highest to lowest) and reduce collision risks: lane change and lane bias. The in-vehicle control computer 150 can be configured to consider a lane change intention on the opposite side of oncoming critical safety oncoming vehicle 430 to maximize the lateral gap with the oncoming vehicle 430.

In response to detecting an oncoming critical safety vehicle and determining that a lane change is not possible, the in-vehicle control computer 150 can be configured to conduct a critical safety bias away from the oncoming vehicle 430. In response to detecting an oncoming critical safety vehicle and determining that lane bias level is insufficient to conduct a critical safety bias away from the oncoming vehicle 430, the in-vehicle control computer 150 can be configured to decelerate with a predetermined longitudinal acceleration and bring the autonomous vehicle 105 to a complete stop. The predetermined longitudinal acceleration may include, for example, 4 m/s2, 5 m/s², 6 m/s2, although other values are also possible without departing from this disclosure.

In response to detecting an oncoming critical safety vehicle, the in-vehicle control computer 150 can be configured to warn the oncoming vehicle 430 with one horn honk and flashing lights until the oncoming vehicle’s 430 predicted lateral gap at TTC is greater than a predetermined threshold distance. The predetermined threshold distance can include, for example, 0.4 m, 0.5 m, 0.6 m, although other values are also possible. In response to detecting an oncoming critical safety vehicle and determining that a lane bias level is insufficient to reach a lateral gap greater than a predetermined number of meters, the in-vehicle control computer 150 can be configured to decelerate with a predetermined longitudinal acceleration in order to reduce speed by a predetermined amount. The predetermined number of meters can include, for example, 0.75 m, 1 m, 1.25 m, the predetermined longitudinal acceleration can include, for example, 2 m/s2, 2.5 m/s², 3 m/s2, and the predetermined amount can include, for example, a reduction by 20%, although other values are also possible.

In response to detecting an oncoming noncritical safety vehicle, the in-vehicle control computer 150 can be configured to consider a non-critical safety lane change intention and perform a lane change if possible. In response to detecting an oncoming noncritical safety vehicle and determining that a lane change is not possible, the in-vehicle control computer 150 can be configured to conduct a non-critical safety bias away from the vehicle.

Example Technique for Modifying Control of an Autonomous Vehicle in Response to Detecting a Non-Compliant Vehicle

One objective of this disclosure includes controlling an autonomous vehicle 105 in response to the detection of a non-compliant vehicle. FIG. 4M illustrates an example method which can be used to control the autonomous vehicle 105 based on the detection of a non-compliant vehicle. The method 400 may be described herein as being performed by one or more processors, which may include the in-vehicle control computer 150.

The method 400 begins at block 401. At block 402, the in-vehicle control computer 150 is configured to determine that another vehicle is violating one or more rules of a roadway based on perception data received from one or more sensors of an autonomous vehicle. For example, the rule violations that the in-vehicle control computer 150 can be configured to detect can include: lane crossing, erratic, speeding, oscillating, intersection, and/or static.

At block 404, the in-vehicle control computer 150 is configured to tag the other vehicle as a non-compliant driver 428. For example, tagging the other vehicle may include the in-vehicle control computer 150 remembering the non-compliant driver 428 for a predetermined length of time after the non-compliant driver 428 has committed a non-compliant maneuver. For example, “remembering” the non-compliant driver 428 may involve the in-vehicle control computer 150 retaining the non-compliant driver 428 tag for the predetermined length of time. The tag may trigger the in-vehicle control computer 150 to perform specific planning actions to avoid the tagged non-compliant driver 428.

At block 406, the in-vehicle control computer 150 is configured to modify control of the autonomous vehicle in response to tagging the other vehicle as a non-compliant driver 428. For example, the in-vehicle control computer 150 can be configured to avoid driving parallel to the tagged vehicle for the predetermined length of time. The method ends at block 408.

Operational Zones

In some embodiments, the digital map with high precision positioning data and information for roadways and surroundings is pre-developed and stored in the memory 175 of the in-vehicle control computer or vehicle computer unit (VCU) 150 of the autonomous truck or autonomous vehicle (AV) 105 shown in FIG. 1 . For the context of this disclosure, the digital map is also referred to as the map. When the autonomous vehicle 105 traverses on roadways on a mission, the in-vehicle control computer 150 may identify different types of operational zones based on mapped data or the real time data detected from the vehicle sensor subsystems 144, including one or more camera, the radar and the LIDAR devices installed on the autonomous vehicle 105.

Location-Driven Traffic Law Library

For driving in different jurisdictions or regions (e.g., different states, different provinces, or different countries), each region may have its own rules of the road that may include different traffic laws and informal rules. Although some of the rules of the road may be similar in the regions, there exist differences. For the autonomous vehicle 105 to cross from one region into another, it has to master the rules of the road in each region that have been developed over time, so that the vehicle can facilitate the orderly and timely flow of traffic in local areas. This is done by developing a digital map that includes metadata of local rules of the road of each region, and store the data in a location-driven traffic law library. As such, when entering a region, the autonomous vehicle may retrieve the local traffic law and customary driving data to effectively localize itself. For each region, the autonomous vehicle 105 may demonstrate the same localization capability by storing the metadata including the rules of the road of different regions in the digital map system that may be stored on the in-vehicle control computer 150 and/or other components of the autonomous vehicle 105.

While the autonomous vehicle 105 may follow the local traffic laws in all aspects, a few aspects may be uniformly shared by the regions. For example, the autonomous vehicle 105 may follow the right-of-way principle for any vehicle coming on a road, a lane or an intersection. The right-of-way principle defines the legal right of one vehicle’s passage over the shared roadway with another vehicle. The autonomous vehicle 105 may use turn signals to indicate that it intends to turn a predetermined length of time before it makes the turn, e.g., at least 8 seconds, 10 seconds, or 12 seconds before turning. And the autonomous vehicle 105 may give priority to a level crossing (railway crossing). There are level crossings without a level crossing barrier or signal, e.g., as shown in the photo in FIG. 5A as an example. The autonomous vehicle 105 can be configured to give priority to any transportation system in the presence of a level crossing. Further, the autonomous vehicle 105 may follow speed limit traffic signs and drive within the speed limit. FIG. 5B shows an example speed limit traffic sign for a local roadway. When a do-not-pass traffic sign is detected by the vehicle sensor subsystems 144, the in-vehicle control computer 150 on the autonomous vehicle 105 may decide to avoid overtaking any vehicles. A do-not-pass sign is shown in FIG. 5C as an example.

In summary, the oversight system 350 may maintain a product requirement document (PRD) that contains the traffic rules for each region, and apply modifications to the PRD traffic law library based on each region’s updated laws. As such the oversight system 350 may establish a set of traffic rules exceptions that apply to each region, and distribute the region traffic rule expectations to each autonomous vehicle 105 on the road.

Autonomous Vehicle Localization

Since the autonomous vehicle 105 is self-driving and may be unmanned, the in-vehicle control computer 150 may track its location and movements. This is usually fulfilled in a few different ways, including detection of lane markings or stationary and moving objects using the sensors on the autonomous vehicle 105, receiving global positioning system (GPS) signals, deriving location from the data generated from visual odometry (VO) or inertial measurement unit (IMU) sensors on the autonomous vehicle 105, applying a dead-reckoning algorithm, retrieving from the digital map stored on the in-vehicle control computer 150, and etc. The in-vehicle control computer 150 of the autonomous vehicle 105 may leverage and fuse some or all available data in order to accurately determine the autonomous vehicle’s location. In addition, the autonomous vehicle 105 may monitor the error of each data source for localization and prioritize the data sources for data fusion.

The autonomous vehicle 105 may detect lane markings for the lane it drives in to decide its location. The autonomous vehicle 105 may detect all lanes of the roadway and use the lane markers and map information to determine the lateral distance between the autonomous vehicle 105 and the road borders, and as such decide its lateral location on the roadway.

In some embodiments, the autonomous vehicle 105 may detect stationary and moving objects to determine its location. This may involve using a visual inertial odometry (VIO) 3D vision as a source to determine the autonomous vehicle’s location. The VIO method becomes important when GPS signal is weak or unavailable, for example, inside a tunnel or an underground parking garage.

In some embodiments, GPS signal can be used to accurately locate the autonomous vehicle 105, which is equipped with GPS receiving antennas to receive GPS signals. The GPS signal can be used for global longitudinal positioning, e.g., in the length direction, on the roadway. However, the GPS signal data also contain position accuracy parameters, such as horizontal dilution of precision (HDOP), position dilution of precision (PDOP), and geometric dilution of precision (GDOP). In some embodiments, the autonomous vehicle 105 may use the HDOP value of the GPS signal parameters to monitor the localization accuracy of the GPS signal. To improve the performance of GPS positioning, including signal strength and positioning accuracy, the autonomous vehicle 105 may have a plurality of GPS modules and/or antennae located on different parts of the autonomous vehicle 105.

Another method of location determining is IMU localization. The autonomous vehicle 105 may use the angle and acceleration data generated from IMU sensors and a dead-reckoning algorithm to update its location. In some embodiments, the autonomous vehicle 105 may retrieve the mapped data, e.g., road width, lane boundaries, lane widths, number of lanes, etc., to improve confidence and accuracy of localization.

In some embodiments, the in-vehicle control computer 150 continuously monitors localization error in order to obtain a high localization confidence and accuracy. For example, the in-vehicle control computer 150 may define a predetermined minimum required localization accuracy, in both lateral and longitudinal directions on the roadway, to complete different tasks.

As an example, if localization accuracy of the received GPS signal degrades on a highway, the autonomous vehicle 105 may plan to drive straight. In other words, the autonomous vehicle 105 may continue driving in the current lane using lane markers detected by the equipped sensors until it regains localization of the GPS signal. In some embodiments, the autonomous vehicle 105 may perform a minimal risk condition (MRC) maneuver to pull over to a shoulder and call for backup from the oversight system 350 if higher accuracy in localization is required to navigate through the path, e.g., if the autonomous vehicle 105 needs to take an oncoming exit, or to operate in local roads, and etc.

In some embodiments, if there is a loss of GPS signal, e.g., when driving in a tunnel, the autonomous vehicle 105 may obtain localization data from other means and continue its path without having a GPS signal, if the in-vehicle control computer 150 determines it is safe to do so. For example, the autonomous vehicle 105 may use location data generated by VIO, which is a fusion of visual odometry (VO) and inertia measurement unit (IMU), a dead-reckoning algorithm, and map data, to update the autonomous vehicle’s 105 local and global positions. In some embodiments, the autonomous vehicle 105 may continue on its path without GPS signal if the autonomous vehicle 105 has sufficient localization accuracy for its upcoming driving tasks from other localization sources such as VIO. For example, the autonomous vehicle 105 may have a sufficient localization accuracy when the localization accuracy is greater than a predetermined minimum required accuracy.

In some embodiments, the autonomous vehicle 105 may pull over safely and call for backup from the oversight system 350 if the autonomous vehicle 105 doesn’t have the required localization accuracy to complete its driving tasks or is unable to recover its localization. In some embodiments, the autonomous vehicle 105 may pull over safely and call for backup from the oversight system 350 if the autonomous vehicle 105 loses lateral localization. As used herein, lateral localization may generally refer to the ability of the autonomous vehicle 105 to stay within lane boundaries. Hardware failures can cause non-recoverable loss of localization, in which none of the localization sources can provide sufficient localization accuracy to complete the driving tasks.

Localization Constraints

In some embodiments, when GPS signal becomes weak and the in-vehicle control computer 150 is able to guide through the weak signal area, the autonomous vehicle 105 may keep driving in its current lane, but may not cross into adjacent lanes occupied by other vehicles.

In some embodiments, if the autonomous vehicle 105 has lateral oscillation that exceeds the lane dividing lines which are used to separate traffic, the in-vehicle control computer 150 may consider performing an MRC maneuver, i.e., to pull over to the shoulder. In some embodiments, if the autonomous vehicle 105 is unable to recognize location of the shoulder, the in-vehicle control computer 150 may decide to stop in the current lane without crossing into an adjacent lane. For example, the in-vehicle control computer 150 can be configured to control the autonomous vehicle 105 to stop with a deceleration that is less than a threshold deceleration to avoid potential damage.

In some embodiments, the in-vehicle control computer 150 may decide not to continue moving the autonomous vehicle 105 on the roadway if the GPS signal is less than a threshold strength for longer than a predetermined length of time in order to reduce the chance of causing property damage or being involved in a crash. The in-vehicle control computer 150 may consider entering the first MRC maneuver, e.g., to pull over to the shoulder, if the GPS signal is less that the threshold signal strength for longer than a predetermined length of time, e.g., 2 minutes, 3 minutes, or 5 minutes, although other values are also possible.

Road Grade Tracking

Most of the roadways are not perfectly horizontal. For example, roadways may have a grade in the longitudinal direction of the road. This grade can also be called slope or gradient. The grade of a road can be determined by the tangent of the angle formed by the road surface (assuming the road surface is laterally even) to an imaginary horizontal plane. In FIG. 5D, when a vehicle climbs the graded road segment from point A to point B for a road distance I, this results in a vertical rise Δh and a horizontal movement d. An angle formed between road surface and the horizontal line is α, as shown in FIG. 5D. The grade of the road is calculated as the ratio of the vertical rise Δh to the horizontal distance d, as expressed by the following equation:

$\sigma = 100 \times \frac{\Delta h}{d}\%$

For example, if the autonomous vehicle 105 drives on a segment of a road rising 15 meters per 100 meters of a horizontal movement, the corresponding grade of the sloped road segment is 15/100 = 15%.

By definition, driving an uphill road means climbing a positive grade, and driving downhill means descending along a negative grade. The high precision map stored in the memory 175 of the in-vehicle computer 150 can be configured to include the grade information, including the absolute grade value, the grade sign in positive (uphill) or negative (downhill) and the grade length (how many miles it occurs), for each segment of the roadways.

When traversing on roadway, the autonomous vehicle 105 may detect grade traffic signs, such as the signs shown in FIGS. 5E-2L as examples. As such, the in-vehicle control computer 150 may obtain grade characteristics, including grade value, grade length and grade sign, from the grade traffic signs or the mapped data.

The autonomous vehicle 105 may also detect grade traffic signs with complementary information related to driving advice. For example, the traffic signs shown in FIGS. 5M-2Q give complementary driving advice or advisories, e.g., “slow” to indicate slow down, “use low gear” to suggest activating the lowest or a lower gear, “check brakes” to ensure that brakes are efficient, and truck speed limits in case the autonomous vehicle 105 is a truck. Some grade traffic signs may have information to inform the presence of a specific turnout for trucks or slow vehicles, so that the vehicles may enter a turnout area to let traffic behind to pass safely.

The autonomous vehicle 105 may trigger pre-developed plans stored on the memory 175 when driving graded roadways. For example, the autonomous vehicle 105 may be configured to operate on roadways with a maximum road grade up to a predetermined grade limit, e.g., 7%, 8%, or 9%. If a roadway having a road grade greater than or equal to the predetermined grade limit, the autonomous vehicle 105 may trigger a first MRC maneuver and stop at a shoulder. When a high grade value traffic sign of a predetermined high grade value, e.g., 5%, 6%, 7%, or more is detected, but less than the predetermined grade limit, the autonomous vehicle 105 may plan to make lane changes so as to position the autonomous vehicle 105 in the right-most lane. When the detected road grade is less than the predetermined high grade value, the autonomous vehicle 105 may follow the speed limit indicated by road grade traffic signs or retrieved from the map. In embodiments where the autonomous 105 vehicle is a truck, the autonomous vehicle 105 may use a truck turnout lane in response to detecting critical situations, such as taking a turn on a road with an acute curve and grade.

When approaching a negative grade, the autonomous vehicle 105 may slow down, e.g., by using a lower or the lowest gear to slow down the vehicle by a predetermined number of meters per square second, e.g., 0.5 m/s²,1 m/s², or 1.5 m/s², until slowing down to within the speed limit. A lower gear enables higher engine speed that results in a higher engine braking torque, and thus engine braking. Slowing down to a lower speed reduces the braking distance for a safe driving. Therefore, on a road with a negative grade, the autonomous vehicle 105, particularly when the autonomous vehicle 105 is a truck, may first use engine braking and employ slip control strategies to manage speed control. In the embodiments that the autonomous vehicle 105 is a truck or large vehicle, emergency braking, e.g., foundation braking plus engine braking, may be applied when the autonomous vehicle 105 is on a negative grade road and an obstacle is detected at a distance less than a predetermined distance.

In some embodiments, when approaching a positive grade road, the autonomous vehicle 105 may plan to drive at a desired speed by increasing throttle or acceleration to compensate for the positive grade effect.

Road Superelevation Tracking

FIG. 5R is a schematic illustrating an example superelevation roadway where the roadway makes a turn. Depending on the curvature of the turn and the speed of a driving vehicle, a large centrifugal force may develop, and this centrifugal force may cause the vehicle to skid or even overturn. As illustrated, superelevation in a road is a transverse inclination provided to the curve portion of a roadway in which the outside edge of the road or pavement is raised with respect to the center line and the inside edge so as to allow fast-moving vehicles to safely pass without overturning and skidding.

As shown in FIG. 5R, before entering a superelevation roadway segment, a center line 502 that is in the middle of the roadway is typically higher than an inside edge 503 and an outside edge 504, as illustrated at start point 506. As such, the roadway forms an amber laterally, allowing rainwater to drain off the road. The start-point 506 indicates where a crown road section 512 begins. From this point on, the banking of the roadway starts to tilt laterally, and the height of the outside edge or pavement 504 starts to rise relative to the center line 502, but remains lower than the center line 502. This means that although the road camber rate changes, the camber still exists. Then, it comes to a first transition point 508 where a level road section 514 starts. At this transition point 508 the outside edge 504 is level with the center line 502. From the first transition point 508 on, the banking of the roadway is inclined laterally from the outside edge 508 to the center line 502 and to the inside edge 503. The inclination rate continues to increase until the road comes to a curved section which is a full superelevation roadway section 515. The full superelevation roadway section 515 starts at a first full superelevation point 510 and ends at a second full superelevation point 511. Within the full superelevation roadway section 515, the outside edge 504 is at a maximum height relative to the center line 502 and the inside edge 503. This higher inclination rate defines the superelevation rate of the superelevation roadway section 515. Then as the roadway straightens, it comes to a second level road section which ends at a second transition point 518, which is equivalent to the first transition point 508. The roadway continues at a second crown roadway section, which ends at an end point 516, which is equivalent to the start point 506. Therefore, when a vehicle, e.g., the autonomous vehicle 105, drives through the roadway sections in FIG. 5R, it follows the direction illustrated by the block diagram shown in FIG. 5S, and goes from the crown section (in) 512, and the level section (in) 514 to the superelevation section 515, and then the level section (out) and finally to the crown section (out).

The crown sections and the level sections, as shown in FIG. 5R, are also called the runout sections and the runoff sections. Therefore, FIG. 5S can also be described as follows: the vehicle follows the direction and goes from the runout section (in) 512, and the runoff section in 514 to the superelevation section 515, and then the runoff section (out) and finally to the runout section (out).

The digital map stored on the in-vehicle control computer 150 may contain superelevation roadway section information, including type, e.g., crown section, level section, full superelevation section, section length and rate, e.g., camber rate, inclination rate, and superelevation rate.

The autonomous vehicle 105 may detect the superelevation roadway sections, e.g., crown section, level section, full superelevation section, using vertical signs, mapped information, or using the inertial measurement unit (IMU) equipped on the vehicle.

According to mapped data and detected roadway data, the in-vehicle control computer 150 may develop plans when approaching a superelevation roadway. For example, when the superelevation rate of the full superelevation section is less than a predetermined threshold value, e.g., 3%, 4%, or 5%, the autonomous vehicle 105 may bypass superelevation road detection and proceed on its path. In some embodiments, when the superelevation rate is within a predetermined range, e.g., greater than 4% and lower than 9.5%, greater than 3% and lower than 10%, or greater than 2.5% and lower than 10.5%, the autonomous vehicle 105 may identify the road as a superelevation road.

When the autonomous vehicle 105 detects a crown section before a superelevation section, e.g., approaching a superelevation roadway, within a predetermined distance, e.g., in the next 400 meters, 500 meters, or 600 meters, it may dynamically adjust its speed to maintain a minimum lateral skidding. When the autonomous vehicle 105 detects a level section ahead of a superelevation section, e.g., when just entered the leading crown section, within a predetermined distance, e.g., in the next 75 meters, 100 meters, or 125 meters, it may maintain its speed according to a predetermined speed formula, which may depend on the roadway superelevation rate. It is possible that a single maximum superelevation rate may not be universally applicable.

When the autonomous vehicle 105 detects a superelevation section before a crown section, e.g., in the direction leaving the superelevation road section, within a predetermined distance, e.g., in the next 400 meters, 500 meters, or 600 meters, it may increase its speed according to a predetermined formula.

Accident Area

The in-vehicle control computer 150 defines an accident area as an area of a roadway which is blocked by stationary vehicles, authorities, or unknown objects. The accident area may include all lanes of the roadway that are partially or entirely blocked, and may include blocked shoulder or edge of the roadway.

Before approaching an accident area, the in-vehicle control computer 150 on the autonomous vehicle 105 may actively detect a potential accident area from a predetermined minimum distance, e.g., at least 400 meters, 450 meters, 500 meters, 550 meters, or 600 meters away. The in-vehicle control computer 150 may detect and follow the guiding signs at the site to safely navigate through the accident area.

In addition to real time detection using the vehicle sensor subsystems 144 on the autonomous vehicle 105, the in-vehicle control computer 150 may receive updated traffic conditions from the oversight system 350 via the wireless network 370 as incident information becomes available from local traffic authorities in real-time. Incidents are reported by incident command system (ICS), national incident management system (NIMS), and other authorities. The oversight system 350 may get this information as soon as it becomes available, and passes it to the autonomous vehicles 105 in the incident area.

The in-vehicle control computer 150 of the autonomous vehicle 105 may be able to detect an accident area by different means. First, the in-vehicle control computer 150 may perceive stationary vehicles and the associated lane(s), shoulder, or edge of the road occupied by the stationary vehicles, from a predetermined minimum distance, e.g., at least 400 meters, 450 meters, 500 meters, 550 meters, or 600 meters away from the site. The stationary vehicles may include other vehicles stopped as first responders and not involved in the actual accident. This programmed proactive approach allows the in-vehicle control computer 150 to get firsthand real time information early and independently, and react accordingly when arriving at the accident area. Secondly, the in-vehicle control computer 150 may detect unknown stationary objects and the associated lane(s), shoulder, or edge of the road that are blocked by the objects from a predetermined minimum distance, e.g., at least 400 meters, 450 meters, 500 meters, 550 meters or 600 meters, away from the site. Unknown objects are defined as objects that the in-vehicle control computer 150 is not able to classify. Examples of unknown objects include vehicles on their sides, vehicles upside down, trailers on the ground, cargo on the ground, etc.

Another detection is for emergency vehicles. In some embodiments, the in-vehicle control computer 150 may proactively detect the stationary emergency vehicles from a predetermined minimum distance, e.g., at least 400 meters, 450 meters, 500 meters, 550 meters, or 600 meters away. The in-vehicle control computer 150 may also detect amber strobes or flashing lights affixed to the emergency vehicles from a predetermined minimum distance, e.g., at least 400 meters, 450 meters, 500 meters, 550 meters, or 600 meters away.

In some embodiments, the in-vehicle control computer 150 may detect cones and the associated lane the cones are placed for from a predetermined minimum distance, e.g., at least 100 meters, 125 meters, 150 meters, or 175 meters away. In some embodiments, the in-vehicle control computer 150 can detect the positions of the cones inside a lane with high accuracy, e.g., within 0.3 meter, 0.4 meter, 0.5 meter, or 0.6 m, when the autonomous vehicle 105 is located within a predetermined distance to the cones, e.g., within 40 meters, 50 meters, or 60 meters. The in-vehicle control computer 150 may use the positions of the cones for navigating through the accident area.

In some embodiments, the in-vehicle control computer 150 can detect people in lanes, shoulder, and on edge of the road from a predetermined minimum distance, e.g., at least 200 meters, 225 meters, 250 meters, or 275 meters away.

In some embodiments, the in-vehicle control computer 150 can detect the hand gestures (e.g., to guide traffic) of law enforcement officers from a predetermined minimum distance, e.g., at least 25 meters, 40 meters, 50 meters, 60 meters, or 75 meters away. Officers may use universal hand signals and gestures for manual traffic direction and control. Two basic hand signals are commonly used. Officers may use an open-hand, palm-out sign to indicate stop. To allow the stopped traffic to proceed, officers may point towards the first stopped vehicle, and then use the other hand to motion the driver to proceed. The autonomous vehicle 105 may follow the guidance from law enforcement authorities to stop or navigate through accident areas.

The in-vehicle control computer 150 may detect mobile traffic signs and variable message signs (VMS) from a predetermined minimum distance, e.g., at least 75 meters, 100 meters, or 125 meters away. Different kinds of mobile traffic signs and variable message electronic signs are commonly used in accident areas to alert oncoming vehicles, and to guide the vehicles through the accident area.

Furthermore, the in-vehicle control computer 150 may detect road flares and their associated lane(s) at nighttime from a predetermined minimum distance, e.g., at least 175 meters, 200 meters, 250 meters, or 275 meters away. Road flares are commonly used by drivers in accident areas to alert oncoming vehicles. It is recommended that road flares are placed 100-150 meters away from the accident area towards the oncoming traffic.

After detection of an accident area, the in-vehicle control computer 150 may decide to navigate the autonomous vehicle 105 through the accident area autonomously when it is safe to do so. Or the autonomous vehicle 105 may stop in a safe area when it is not safe to pass the accident area.

In some embodiments, when approaching an accident area, the autonomous vehicle 105 may proceed in such a way to leave at least one full vacant lane distance from its vehicle body to the accident area if it is safe to do so. The autonomous vehicle 105 may slow down to a predetermined safe speed and maintain the speed when it approaches the accident area. Further, the autonomous vehicle 105 may merge into the farthest lane from the accident area. In some embodiments, the autonomous vehicle 105 may safely stop when it is not possible, or unsafe, to pass the accident area. If driving in a two-lane road in which a lane is blocked by an accident, or driving in a single-lane road in which the shoulder is blocked by an accident, the autonomous vehicle 105 may slow down to a predetermined speed, e.g., 15 mph, 20 mph, or 25 mph, and pass the accident area. The move over laws may be different by region. To obey a move-over law, the autonomous vehicle 105 may vacate the lane closest to the accident area if it is safe to do so. If the road has only two lanes (or one lane with accident area in the shoulder), the autonomous vehicle 105 may slow the speed to 20-30 mph.

The autonomous vehicle 105 may follow the traffic flow as they navigate through and pass the accident area. The autonomous vehicle 105 may change lanes if required when following the traffic flow.

In some embodiments, when all lanes are blocked the autonomous vehicle 105 may stop on the shoulder of the road on the side that is closer to its current lane if it is safe to do so. In some embodiments, the vehicle may stop safely in its current lane when it is not safe to change lanes or to move over to the shoulder or edge of the road. In some embodiments, the vehicle may stop at least 50 meters before or away from the accident area if it is safe to do so. The in-vehicle control computer 150 on the autonomous vehicle 105 may communicate with the oversight system 350 after full stop to get guidance.

In some complex situations, the autonomous vehicle 105 may stop on the shoulder of the road on the side that is closer to its current lane if it is safe to do so. In some embodiments, the in-vehicle control computer 150 on the autonomous vehicle 105 may communicate with the oversight system 350 via the wireless network 370 and request for backup. In some complex situations, action may be either unclear or highly risky for the autonomous vehicle 105. Examples of the complex situations may include blocked road because of mega accidents or infrastructure damage, e.g., falling off a bridge, low road visibility due to smoke, and etc.

If the autonomous vehicle 105 has completely stopped and waited due to a complex situation, the autonomous vehicle 105 may communicate with the oversight system 350 and seek guidance before moving again.

Road Blockage Classification and Handling

In some embodiments, in the digital map stored in the memory 175 of the in-vehicle control computer 150, a road blockage is defined as a temporary closure of a road where the transit of vehicles is not permitted. A full road closure is designed to eliminate the exposure of vehicles to work zones and workers by temporarily closing a facility for rehabilitation, maintenance, or emergency tasks.

The in-vehicle control computer 150 of the autonomous vehicle 105 may detect traffic signs that indicate the presence of a road blockage. Examples of road blockage signs are shown in FIGS. 5T-2V. In some embodiments, once road blockage signs are detected, the in-vehicle control computer 150 may inform the oversight system 350. The in-vehicle control computer 150 may detect any real time differences between what is perceived by the vehicle sensor subsystems 144 and what is mapped. When a conflict is detected between the mapped data and perceived data for a road blockage, the in-vehicle control computer 150 may inform the oversight system 350. In some embodiments, the in-vehicle control computer 150 may continuously update the map stored in the memory 175 with road blockage information, and the location of the known road blockage.

Traffic control devices (or road blockage devices) are defined in the map as road barriers, circular flashing amber lights, cones, barricades, etc., as shown in FIGS. 5W-2Y as examples. The in-vehicle control computer 150 may detect traffic control devices for road blockage at a predetermined distance from the devices, e.g., at 200 meters, 222 meters, or 250 meters.

When a road blockage is detected and no alternative route is available, the autonomous vehicle 105 may stop on a shoulder or the emergency lane, or pull over to the rightmost lane, and inform the oversight system 350. The autonomous vehicle 105 may activate its hazard lights. However, when a detour is indicated by traffic signs, the autonomous vehicle 105 may follow the direction indicated by the signs.

Parking Lot

The in-vehicle control computer 150 may operate the autonomous vehicle 105 in outdoor parking lots. Also, the in-vehicle control computer 150 may be able to park the autonomous vehicle 105 in a designated parking spots on the pre-planned route as determined by a base station, or by temporary and dynamic navigation planning.

After parking, the in-vehicle control computer 150 may notify the base station with the vehicle’s location and health report. If the vehicle is temporarily parked and the trip is not over, the base station may be able to remotely resume the trip over the wireless network 370. Otherwise, if the trip is over, the in-vehicle control computer 150 may automatically turn off the system and engine.

Double triggers are required to start an autonomous trip for the system.

Unmapped Construction Zone

The digital map stored in the memory 175 of the in-vehicle control computer 150 on the autonomous vehicle 105 may be updated continuously or periodically to include the newest developments on roadways. However, new construction zones or those construction zones in remote areas may not be in the digital map. An unmapped construction zone is defined as a section of the roadway that is not indicated in the map as a construction zone, but with active roadwork going on that may involve a lane closure, detour, or having moving equipment. Upon detection of an unmapped construction zone during a mission, the in-vehicle computer 150 of the autonomous vehicle 105 may report the unmapped construction zone to the oversight system 350.

In some embodiments, the autonomous vehicle 105 may use an alternate route if available and avoid entering into the construction zone as indicated by the traffic signs while approaching an unmapped construction zone. FIG. 5Z and FIG. 5AA show examples of construction-zone road signs. The in-vehicle control computer 150 may notify the oversight system 350 when a detour is required because of an unmapped construction zone.

The in-vehicle control computer 150 may detect traffic signs at the construction zone and navigate through the zone by prioritizing the use of the virtual walls over the lane lines. FIG. 5AB and FIG. 5AC show examples of traffic signs and traffic control or channeling devices. When these traffic signs and the traffic control devices are detected, the in-vehicle control computer 150 models a virtual wall for construction zone that virtually separate the construction zone from the drivable roadways. Traffic signs and channelizing devices may include cones, barrels, signs, large vehicles, or construction zone flaggers or workers in bright colored vests, as shown in FIG. 5AD-2AJ as examples. The autonomous vehicle 105 may follow the corresponding directions indicated by the signs, the devices, and signals from the zone flaggers.

Approaching a construction zone, the in-vehicle control computer 150 may detect the start of a construction zone by detecting the relevant construction zone traffic signs. For example, when a road-work-ahead traffic sign shown in FIG. 5AK is detected, it means that the autonomous vehicle 105 is approaching a construction zone. When a road sign with reduced speed limit is detected by the in-vehicle control computer 150 in a work zone, the autonomous vehicle 105 may dynamically adjust the speed according to the traffic signs. For example, the road signs shown in FIG. 5AL indicate that the speed in the work zone is reduced from 70 kmph to 50 kmph. An end of the construction zone may be an area that meets conditions predefined in the in-vehicle control computer 150 of the autonomous vehicle 105.

As shown in FIG. 5AM-2AN, photos of example human controllers or flaggers, and FIG. 5AO-2AT, schematics of human controllers or flaggers, traffic control signs and/or devices may be held by human controllers or construction zone flaggers to control traffic flow. Human controllers may use hand signals to stop traffic, slow down traffic, or allow traffic to proceed.

After entering a construction zone, the autonomous vehicle 105 may drive in the right lane when available. As shown in FIG. 5AU, the in-vehicle control computer 150 may detect the white solid stop lines while navigating a construction zone. And there may be traffic signs, like the be-prepared-to-stop sign shown in FIG. 5AV, to caution the autonomous vehicle 105 to prepare to stop. Further, the autonomous vehicle 105 may plan a lane change into a lane that is not behind marker cones when the cones are to indicate lane merging within the construction zone. The autonomous vehicle 105 may plan a lane shift as required within the construction zone by following the traffic signs and virtual walls. Lane shifting is indicated in FIG. 5AW by solid white lines, and in FIG. 5AX-2BA by on road and traffic signs.

The in-vehicle control computer 150 may detect motorized traffic in a construction zone that moves from an area behind barricades or traffic cones and coming in the trajectory of the autonomous vehicle 105 through the opening in those barriers. FIG. 5BB shows an example traffic sign indicating that there may be truck movement in the work zone. The autonomous vehicle 105 may prepare for a full stop or slow down to avoid a collision.

Interchange Navigation

When developed, the map stored in the memory 175 of the in-vehicle control computer 150 intends to include the locations of all the interchanges and their types. The types of interchanges may include a diamond interchange, a full cloverleaf interchange, a partial cloverleaf interchange, a trumpet interchange, a three-leg directional interchange, a four-leg all-directional interchange, a semi-directional interchange, a single entrance and/or exit interchange (partial interchange), and a single point interchange (SPI). There are more interchange types that are not included in the above list, e.g., a double crossover diamond interchange, a displaced left turn interchange, a diverging diamond interchange, and etc.

The in-vehicle control computer 150 may perceive an interchange with different attributes, including on ramp /off ramp, ramp curvature, merge in/merge out lanes, dedicated lane for divergence, presence of traffic signals, and etc. In some embodiments, the in-vehicle control computer 150 may detect ramp properties such as straight, curved, angle of curvature, at least from a predetermined distance away, e.g., at least 200 meters, 220 meters, 250 meters, 270 meters, or 300 meters away.

The in-vehicle control computer 150 on the autonomous vehicle 105 may detect the type of the interchange it approaches. For example, the in-vehicle control computer 150 may determine that the interchange is a diverging diamond interchange when the in-vehicle control computer 150 detects an off ramp first and there are traffic control devices such as lights, pavement markings, or physical barriers, at the interchange. FIG. 5BC schematically illustrates a diverging diamond interchange and traffic flow directions.

At a diverging diamond interchange, the autonomous vehicle 105 may follow the traffic signal and change lanes to the left side of the road in the interchange. If the autonomous vehicle 105 wants to continue on the same road, it may continue on the road. In case the autonomous vehicle 105 wants to exit and get on to the other freeway, it may take the left lane and exit the road to merge into the other road.

An example full cloverleaf interchange is shown FIG. 5BD. The in-vehicle control computer 150 may determine that the interchange is a full cloverleaf intersection when the following conditions are met: the off ramp merge is encountered first; the on-ramp lane merges into the freeway next; each freeway is connected with two circular ramps with 270° turns exist next to the interchange with each of them going in an opposite direction.

At a cloverleaf interchange, the autonomous vehicle 105 may approach and take the first off ramp to interchange onto the other freeway. The autonomous vehicle 105 may plan to enter the ramp at the speed limit indicated by the mapped data or detected from a real time traffic sign. When the autonomous vehicle 105 crosses the first off ramp and intends to take the next 270° circular off ramp, it may plan to enter the ramp at a speed that is a predetermined percentage, e.g., 10%, 12%, 15%, 18%, lower than the speed limit and dynamically adjust the speed to compensate for the gradient and maintain a predetermined lateral deceleration, e.g., no more than 1 m/s², 2 m/s², or 3 m/s².

When merging from a ramp onto a highway, the autonomous vehicle 105 may merge with a non-critical safety lane change intention. The vehicle may use appropriate light indication to let oncoming or following vehicles be aware of its intention to merge and to change lane. When merging from a circular ramp to a highway, the autonomous vehicle 105 may perform a zipper merge. An example zipper merge is shown in FIG. 5BE.

Intersection Roundabout

In some embodiments, a roundabout is a circular intersection where traffic travels around a central island in a counter-clockwise (or clockwise depending on the laws of the region) direction that is defined and saved in the digital map on the in-vehicle control computer 150. Roundabouts are categorized based on the number of lanes and inscribed circle diameter, as shown in the table in FIG. 5BF.

In some embodiments, the digital map stored on the in-vehicle control computer 150 may contain data of certain roundabouts but not all roundabouts. For example, a roundabout may be mapped if the inscribed circle diameter of the roundabout is wider than a predetermined number of feet, e.g., 75 ft, 100 ft, or 125 ft. And the map may contain data for all multi-lane roundabouts.

In some embodiments, the autonomous vehicle 105 may map urban single-lane roundabouts with truck apron, urban double-lane roundabouts, rural single-lane roundabouts with truck apron, rural double-lane roundabouts. Truck apron which effectively makes the roundabout multi-lane is the area near the center and around the island of the roundabout that gives large vehicles extra space to accommodate the vehicle turning path as the vehicle makes its way through the roundabout. The apron is slightly elevated and visually different from the circulating roadway.

Mini roundabouts, i.e., smaller roundabouts that is not mapped by the digital map for the autonomous vehicle 105, may have a sign with a blue circle and white arrows circling clockwise, as shown in FIG. 5BG.

The in-vehicle control computer 150 of the autonomous vehicle 105 may detect an oncoming roundabout sign from at least 150 meters away. The in-vehicle control computer 150 may detect the type and number of lanes of an oncoming roundabout from at least a predetermined distance, e.g., 75 ft, 100 ft, or 125 ft.

In some embodiments, the in-vehicle control computer 150 may detect traffic signs and/or pavement markings that guide or prohibit certain movements. A yield ahead sign may be used on all approaches to a roundabout in advance of the yield sign. A circular intersection sign or a roundabout ahead sign may be installed on each approach in advance of the roundabout. Different roundabout traffic signs are shown as examples, including a yield ahead sign in FIG. 5BH, a multi-lane roundabout sign in FIG. 5BI, and two upcoming roundabout signs in FIGS. 5BJ and 2BK.

In some embodiments, in-vehicle control computer 150 may detect the curb of the central island of a roundabout at least 10 meters before entryway of the roundabout. In some embodiments, the in-vehicle control computer 150 may detect the apron of the central island.

In some embodiments, the in-vehicle control computer 150 may detect the vehicles that are inside the circle of the roundabout at least a predetermined minimum distance away, e.g., at least 5 meters, 10 meters, or 15 meters away, from the autonomous vehicle 105′s entryway of the roundabout. In some embodiments, the in-vehicle control computer 150 may detect the vehicles that are in the closest entry lane from the left side and 20 meters away or less from the entryway of the roundabout, at least a predetermined minimum distance away, e.g., at least 5 meters, 10 meters, or 15 meters away, from the autonomous vehicle 105′s entryway of the roundabout. The in-vehicle control computer 150 may detect the vehicles that are in its exit way if the vehicles are within a predetermined distance, e.g., 10 meters, 15 meters, or 20 meters, from the exit way.

When approaching a roundabout, the in-vehicle control computer 150 may develop plans according to mapped data and detected data to navigate through the roundabout safely. In the process of traversing the roundabout, the autonomous vehicle 105 may slow down its speed for safety reasons. In some embodiments, the in-vehicle control computer 150 may select a predetermined maximum speed, e.g., 3 mph, 5 mph, 8 mph, or 10 mph, at a predetermined distance from the entryway of the roundabout, e.g., 8 meters, 10 meters, or 15 meters from the entryway of the roundabout.

For a multi-lane roundabout, the autonomous vehicle 105 may choose the best entry lane for the intended exit and move toward the exit at least a predetermined distance, e.g., at least 30 meters, 40 meters, or 50 meters, before the entryway of the roundabout. The choice of entry lane is based on the vehicle’s destination and planned exit lane. The autonomous vehicle 105 may follow the guidance provided by traffic signs and/or mapped data and move to the planned lane.

The autonomous vehicle 105 may move to the left entry lane if it is planning to make a left turn or U-turn. In some embodiments, the autonomous vehicle 105 may move to the right entry lane if it is planning to make an immediate right turn. In some embodiments, the autonomous vehicle 105 may stay in its current lane if it is planning to go straight.

If there is a vehicle(s) inside the circle of the roundabout on the left side of the entryway of the autonomous vehicle 105, the autonomous vehicle 105 may yield to the traffic inside the circle and perform a full stop before the entryway and crosswalk. In some embodiments, the autonomous vehicle 105 may yield and fully stop before the entryway and crosswalk if there is a vehicle(s) in the closest entry lane from the left side, and less than a predetermined distance from the entryway of the roundabout, e.g., 15 meters or less, 20 meters or less, or 25 meters or less.

The autonomous vehicle 105 may fully stop before the entryway and crosswalk, and yield to pedestrians and bicyclists crossing the roadway. In some embodiments, the autonomous vehicle 105 may fully stop before the entryway and crosswalk if its planned exit way of the roundabout is blocked. The in-vehicle control computer 150 of the autonomous vehicle 105 may contact the oversight system 350 to seek guidance if the exit way remains blocked for a time equal to or longer than a predetermined length of time. The exit way of the roundabout is defined as blocked if there is less than a predetermined amount of available space, e.g., 15 meters, 20 meters, or 25 meters, in that lane after the crosswalk.

The autonomous vehicle 105 may merge into the roundabout (heading to the right) if the roundabout is available to enter safely. In some embodiments, the in-vehicle control computer 150 predicts successful merging into the roundabout based on a predetermined length of time, e.g., 15 seconds required time (X) + 5 seconds safety offset time (Y), to complete its merge without confronting any other vehicles. If there is no vehicle inside the circle on the left side of the entryway of the autonomous vehicle 105 and there is no vehicle in the closest entry lane on the left side of the autonomous vehicle 105, 20 meters away or less from the entryway of the autonomous vehicle 105, the in-vehicle control computer 150 considers it is safe to merge into the roundabout.

In the embodiments that the autonomous vehicle 105 is a truck, it may take advantage of law for driving through roundabouts. Some regions have laws that give right-of-way to semi-trucks and large vehicles in roundabouts. Vehicles are prohibited from driving next to trucks and large vehicles inside the circle of the roundabout. If the autonomous vehicle 105 is a truck, it may merge into the roundabout in a way to use and block two lanes in a multi-lane roundabout. This is to ensure that the autonomous vehicle 105 has enough space to accommodate its turning path. By law, vehicles are prohibited from driving next to trucks and large vehicles inside the circle of the roundabout.

Once inside a roundabout, the autonomous vehicle 105 may stay in its lane and drive safely inside the circle of the roundabout while maintaining a safe distance (curvature corrected following distance) from the front vehicle(s) until it reaches its planned exit. The autonomous vehicle 105 may move in a counterclockwise direction inside the circle of the roundabout (or clockwise in some regions depending on the traffic laws), and can drive at least 5 mph slower than posted speed limit. In some embodiments, the autonomous vehicle 105 may avoid driving next to other vehicles inside the circle of the roundabout, and avoid stopping inside the circle of the roundabout. In some embodiments, the autonomous vehicle 105 may avoid passing other vehicles inside the circle of the roundabout, and may continue moving around the circle in the same lane if it misses its planned exit. Posted speed limit inside the roundabouts is mostly between 15 mph and 25 mph, depending on the location and type of the roundabout.

At exit, the autonomous vehicle 105 may exit the roundabout and merge into the planned exit way safely. In some embodiments, the autonomous vehicle 105 may abort exiting if there’s another vehicle driving in parallel to it on the right side, or if its planned exit way of the roundabout is blocked. If the planned exit way remains blocked after a predetermined number of tries, e.g., 3 tries, 4 tries, or 5 tries, the autonomous vehicle 105 may exit to the next safe exit way and pull over safely to call the oversight system 350 to seek guidance.

The autonomous vehicle 105 may continue driving around the circle of the roundabout in the same lane to reach the exit way again if exiting is aborted.

The autonomous vehicle 105 may yield to emergency vehicle(s) inside the circle of roundabout or approaching the roundabout. The autonomous vehicle 105 may fully stop before the entryway and crosswalk if the autonomous vehicle 105 has not entered the roundabout. The autonomous vehicle 105 may exit to its planned exit way, pull over immediately, and yield to emergency vehicle(s) if the autonomous vehicle 105 is already inside the circle of the roundabout when it detects emergency vehicle(s) inside the roundabout or approaching the roundabout.

Two-Way Left Turn Lane

A two-way left-turn lane is a center lane that allows vehicles from each direction to make left turn using the same lane. It is permissible to cross the solid yellow line to enter the shared turn lane. Center lane or two-way left turn lane is defined and stored in the digital map. A vehicle may only enter the turning lane close to where it intends to turn. The vehicle shall watch for oncoming vehicles in the lane. A two-way left turn center lane is shown in FIG. 5BL.

A two-way left turn (TWLT) lane is indicated by TWLT signs, as shown in FIG. 5BM and FIG. 5BN as examples. The in-vehicle control computer 150 may detect two-way left turn lane signs at a predetermined distance, e.g., 200 meters, 222 meters, 250 meters, or 275 meters, when the autonomous vehicle 105 approaches a TWLT sign. The in-vehicle control computer 150 may also detect pavement marking indicating the presence of a two way left turn lane in the road. FIG. 5BO is a schematic showing a two-way left turn lane in the middle of the road with pavement markings. If the in-vehicle control computer 150 determines that a detected two-way left turn lane is not mapped, it may inform the oversight system 350 in order to update the map.

Before taking a left turn on a TWLT lane, the in-vehicle control computer 150 may identify the entry point in the lane as given in the map at a predetermined distance, e.g., 200 meters, 222 meters, 250 meters, or 275 meters, before the autonomous vehicle 105 reaches the planned turn. In some embodiments, the in-vehicle control computer 150 may estimate a possible entry point into the TWLT lane at a predetermined maximum allowed distance, e.g., 250 feet, 300 feet, 350 feet, or 400 feet, before the autonomous vehicle 105 reaches the planned entry into the TWLT lane. The maximal allowed distance may vary for each region or may not be applicable. For example, in the state of California this distance is about 200 feet. FIG. 5BP schematically illustrates the estimation of entry point into a TWLT lane.

When approaching the entry point into a TWLT lane, the autonomous vehicle 105 may perform a lane change at least a predetermined distance, e.g., 50 meters, 55 meters, 60 meters, or 65 meters, before the estimated entry point, so that the autonomous vehicle 105 is positioned in the adjacent lane of the TWLT lane. When the autonomous vehicle 105 is positioned in the right side of the TWLT lane, the in-vehicle control computer 150 may keep the front and rear left turn signals on. In some embodiments, the in-vehicle control computer 150 may actively detect vehicles which are already in TWLT lane that may be either heading in the same direction as the autonomous vehicle 105 or driving in opposite direction. The in-vehicle control computer 150 may detect details of the vehicles driving in opposite direction of the autonomous vehicle 105 and determine their speed, position, and sizes.

The in-vehicle control computer 150 may abort the lane change into the TWLT lane if there is not enough lateral or longitudinal space available for the autonomous vehicle 105 to merge into the TWLT lane. In this case, the autonomous vehicle 105 may continue to move forward in the TWLT lane’s right lane, deactivate the left turn signals and inform the oversight system 350. In some embodiments, the in-vehicle control computer 150 may plan an alternate route to continue its mission.

If there is enough space laterally and longitudinally, the in-vehicle control computer 150 may perform a lane change so that the autonomous vehicle 105 is positioned in the TWLT lane. Once entered the TWLT lane the autonomous vehicle 105 may slow down and come to a stop where the vehicle’s front most point reaches the intersecting point of the TWLT lane with the left lane where the autonomous vehicle 105 intends to turn. In some embodiments, the autonomous vehicle 105 may keep its left turn signal activated during the time when it is in TWLT lane and performing left turn.

The in-vehicle control computer 150 may detect vehicles in the opposite direction of the roadway and in the planned TWLT lane at a predetermined distance, e.g., 200 meters, 222 meters, 250 meters, or 275 meters, from the entry point in the TWLT lane.

The in-vehicle control computer 150 may yield to any oncoming vehicle from the opposite direction in the roadway while ensuring a predetermined time to collision (TTC), e.g., 6 seconds TTC, 7 seconds TTC, or 8 seconds TTC, before taking left turn. Also, the in-vehicle control computer 150 may yield to any pedestrians crossing the lane that the autonomous vehicle 105 plans to turn into, while ensuring a predetermined TTC, e.g., 6 seconds TTC, 7 seconds TTC, or 8 seconds TTC, with oncoming traffic before start taking the turn.

The in-vehicle control computer 150 may estimate whether the lane in which it is turning left into is clear so that the rearmost point of the autonomous vehicle 105 can cross the intersection before any oncoming vehicle approaches the intersection. When the path of left turn is clear, the autonomous vehicle 105 may accelerate and adjust its speed to follow the speed limit of the left lane it is turning into. In case the autonomous vehicle 105 needs to align its position with the left lane that it intends to turn into or when the in-vehicle control computer 150 does not have a clear view of the left lane, the autonomous vehicle 105 may creep forward for a predetermined maximum distance, e.g., 2 meters, 3 meters, or 4 meters, at a predetermined speed, e.g., 4 mph, 5 mph, or 6 mph.

Traffic Light Detection and Response

Traffic lights and their locations are included in the digital map stored in the memory 175 of the in-vehicle computer 150. In some embodiments, when the autonomous vehicle 105 traverses on a road, the in-vehicle control computer 150 detects traffic light signs at least a predetermined distance away, e.g., 200 meters, 222 meters, 250 meters, or 275 meters away. An example traffic light sign is shown in FIG. 5BQ. The in-vehicle control computer 150 may detect and identify the traffic light at least a predetermined distance away, e.g., 200 meters, 222 meters, 250 meters, or 275 meters away.

When the autonomous vehicle 105 approaches an intersection, the in-vehicle control computer 150 may detect an intersection traffic sign at least a predetermined distance away, e.g., 200 meters, 222 meters, 250 meters, or 275 meters away. As shown in FIG. 5BR-5BT as examples, intersection traffic signs may include left-turn-yield-on-green sign, no-turn-on-red sign, no-turn-on-red-except-from-right-lane sign, etc. FIGS. 5BU and 2BV show photos of two more examples of intersection traffic signs.

When a traffic light sign is detected, the autonomous vehicle 105 may slow down by a predetermined percentage of the speed limit, e.g., 8%, 10%, or 12%. The in-vehicle control computer 150 may detect a speed limit sign at least a predetermined length of time in advance, e.g., 8 seconds, 10 seconds, or 12 seconds in advance, or a predetermined distance ahead, e.g., 250 meters, 300 meters, or 350 meters, before reaching it, whichever distance is greater.

When a red signal light is detected, the autonomous vehicle 105 makes a complete stop before the vehicle’s front bumper reaches the stop line and no farther than a predetermined distance, e.g., 3 meters, 4 meters, or 5 meters, from the stop line. When a blinking red signal light is detected, the autonomous vehicle 105 may make a complete stop before the vehicle’s front bumper reaches the stop line and no farther than a predetermined distance, e.g., 3 meters, 4 meters, or 5 meters, from the stop line. In some embodiments, the autonomous vehicle 105 may treat the intersection as a stop sign intersection. In some embodiments, when a red arrow signal light is detected, the autonomous vehicle 105 makes a complete stop before the vehicle’s front bumper reaches the stop line and no farther than a predetermined distance, e.g., 3 meters, 4 meters, or 5 meters, from the stop line.

In some embodiments, when a green arrow signal light is detected, if the autonomous vehicle 105 plans to turn, it may yield to any vehicle, bicycle, or pedestrian still in the intersection. In some embodiments, the autonomous vehicle 105 may proceed and follow the direction indicated by the green arrow. In some embodiments, when solid green signal light is detected, the autonomous vehicle 105 may proceed crossing the intersection.

In some embodiments, when a solid yellow signal light is detected, the autonomous vehicle 105 may make a complete stop before the vehicle’s front bumper reaches the stop line, and no farther than a predetermined distance, e.g., 3 meters, 4 meters, or 5 meters, from the stop line. When a blinking yellow signal light is detected, the autonomous vehicle 105 may slow down by a predetermined percentage of the speed limit, e.g., 8%, 10%, or 12 %, of the speed limit. The autonomous vehicle 105 may yield to any pedestrians, bicyclists, or vehicles in the intersection.

There are locations that traffic signs are installed together with traffic light. For example, when a solid green light signal and a left-turn-yield-on-green sign are detected together, if the autonomous vehicle 105 plans to turn left, it may yield to oncoming traffic before taking the left turn. When a solid red signal light and a no-turn-on-red sign are detected together, if the autonomous vehicle 105 plans to turn, it makes a complete stop until the traffic signal changes to green before making the turn. When a solid red signal light and a no-turn-on red-except-from-right-lane sign are detected, as shown in FIG. 5BT for the traffic sign, if the autonomous vehicle 105 is in the right lane and plans to turn right, it may make a complete stop before proceeding to make the right turn.

Intersection Navigation

The digital map stored in the memory 175 of the in-vehicle control computer 150 intends to store data for different types of intersections, including their locations and details of their types. The types of intersections include four-way intersection, T-junction, Y-intersection, traffic circle intersection, fork intersection, controlled intersection, uncontrolled intersection, and pedestrian crosswalk intersection. Based on behavior, intersections can be categorized as controlled intersection and uncontrolled intersections. Besides retrieved intersection data from the map, the in-vehicle control computer 150 may actively inspect and identify different intersection types when it is on road. By definition, a controlled intersection employs stop signs, traffic signals or emergency personnel, and an uncontrolled intersection is a road intersection with no traffic light or road signs to indicate the right-of-way.

An intersection can also be classified as a stop sign intersection, a traffic signal intersection, a yield intersection, an intersection allowing U-turn, an intersection with turning lanes, and etc.

In some embodiments, when approaching an intersection, the in-vehicle control computer 150 may detect different moving objects such as pedestrians, cyclists, other vehicles, and emergency vehicles at a predetermined minimum distance, e.g., 200 meters, 222 meters, 250 meters, 275 meters, or 300 meters, from the autonomous vehicle 105. When a moving object is detected when the autonomous vehicle 105 is approaching an intersection, it may come to a complete stop at a predetermined distance, e.g., 3 meters, 4 meters, or 5 meters away from the object.

When a crosswalk is detected, the autonomous vehicle 105 may stop with the vehicle’s front most point behind the crosswalk line but no further than a predetermined distance, e.g., 3 meters, 4 meters, or 5 meters, from the crosswalk line.

Roundabouts or traffic circles are designed with a truck apron as described in a previous section. A truck apron is a raised section of concrete around the central island of a roundabout that acts as an extra lane for large vehicles and vehicles with trailers. The back wheels of an oversized vehicle can ride up on the truck apron so that it may more easily complete the turn, while the raised portion of concrete discourages smaller vehicles from using it. A truck apron is shown in FIG. 5BY as an example.

Before entering a roundabout or traffic circle, the autonomous vehicle 105 may slow down to below a predetermined speed, e.g., 15 mph, 20 mph, 25 mph. At the traffic circle, the autonomous vehicle 105 may stop and wait up to a predetermined length of time, e.g., 4 seconds, 5 seconds, or 6 seconds, before entering in the circulating traffic. Vehicles already inside the roundabout have the right of way. If other vehicles have not attempted to proceed through the intersection within that time, the autonomous vehicle 105 may proceed through vehicles with the right of way. FIGS. 5BZ and 2CA schematically shows examples of roundabouts and traffic flows. When the autonomous vehicle 105 enters and exits a roundabout, if the in-vehicle control computer 150 detects that a crosswalk is present at the roundabout, it may yield to the pedestrians using the crosswalk.

When the autonomous vehicle 105 approaches a traffic circle and detects that an emergency vehicle is in the roundabout, the autonomous vehicle 105 may enter the traffic circle after the emergency vehicle has exited. In some embodiments, when the autonomous vehicle 105 encounters an emergency vehicle when it is in the roundabout, it may continue to exit and then move to the right side to stop.

A fork intersection is an intersection where one road splits into multiple roads. For example, one lane of the main road divides into two mini-lanes with one mini-lane connecting to a joining road and the other mini-lane continuing along the road’s original path. Typically, at a fork intersection there is a median area separating the two dividing roads of the main roadway. An example fork intersection is shown in FIG. 5CB.

At an uncontrolled intersection, the autonomous vehicle 105 may yield the right of way to any vehicles that are traveling in lanes not required to stop and with paths intersecting the vehicle’s planned path. In some regions, such as in the state of Arizona, the autonomous vehicle 105 may treat any unregulated intersection as an all way stop intersection and come to a complete stop before going through. Also, when making left or right turn, turn into the closest lane, as shown in FIG. 5CC.

At an intersection, the in-vehicle control computer 150 may actively detect any non-compliant driver at a predetermined distance, e.g., 100 meters, 125 meters, 150 meters, 175 meters, or 200 meters, before reaching the intersection. When a non-complaint driver is detected at an intersection, in order to avoid a collision, the autonomous vehicle 105 may yield until the non-complaint driver has cleared the intersection.

At a four-way intersection, the autonomous vehicle 105 may proceed through the intersection if any through traffic vehicle comes to a complete stop in order to allow vehicle to transition to its target lane. A four-way intersection is schematically shown in FIG. 5CD.

Crosswalks

The digital map stored in the memory 175 of the in-vehicle control computer 150 intends to include information and location for all crosswalks. But the in-vehicle control computer 150 may detect crosswalk signs at least a predetermined distance, e.g., 200 meters, 222 meters, 250 meters, or 275 meters, from the crosswalk. FIG. 5CE-5CM show examples of crosswalk traffic signs. When a conflict is detected between mapped information and perceived crosswalk information, the in-vehicle control computer 150 may inform the oversight system 350 and take the perceived information as higher priority. The in-vehicle control computer 150 may also inform the oversight system 350 if a non-mapped crosswalk sign or crosswalk road marking is detected in order to update the map.

When crosswalk markings or crosswalk sign is detected, the autonomous vehicle 105 may slow down to a predetermined speed, e.g., 15 mph, 20 mph, or 25 mph. In some embodiments, when crosswalk markings and stop traffic sign are detected, the autonomous vehicle 105 may stop no closer than a predetermined distance, e.g., 0.5 meter, 1 meter, or 1.5 meter, from the crosswalk line and wait until no pedestrians are in the crosswalk before proceeding to cross the crosswalk. When crosswalk markings and red traffic light are detected, the autonomous vehicle 105 stops no closer than a predetermined distance, e.g., 0.5 meter, 1 meter, or 1.5 meter, from the crosswalk line and wait until there no pedestrians in the crosswalk before proceeding to cross the crosswalk. Similarly, when crosswalk markings and yield traffic sign are detected, the autonomous vehicle 105 stops no closer than a predetermined distance, e.g., 0.5 meter, 1 meter, or 1.5 meter, from the crosswalk line and wait until there no pedestrians in the crosswalk before proceeding to cross the crosswalk.

Dynamic Zone Detection and Response

A dynamic zone is defined as a zone where traffic patterns vary on periodic basis. For example, there may be periodic lane closures and openings based on traffic volume or time of the day. FIG. 5CN shows lane arrangements in a two-way road at different times of a day. On the left side of FIG. 5CN, there are 2 lanes to the right and 2 lanes to the left. But at a different time of the same day, as shown on the right side of FIG. 5CN, the lane arrangement is converted to 3 lanes to the right and 1 lane to the left.

As the autonomous vehicle 105 travels on a road and detects the newest changes, the digital map stored in the memory 175 of the in-vehicle control computer 150 may continuously or actively update the latest information about dynamic zones, including location and closure timing information. FIG. 5CO schematically shows another example of lane changes at an intersection.

The in-vehicle control computer 150 may detect the dynamic zone change signs in lane or on shoulder at a distance greater than the deceleration distance. In some embodiments, the in-vehicle control computer 150 may detect the lane boundaries in the dynamic zone. A lane may be defined within the left and the right boundaries defined by yellow road marking, white lines, road edges, LED lights, barricades, and etc. FIG. 5CP-2CT show examples of lane changing and boundary marking.

The in-vehicle control computer 150 may consider the dynamic changes in lanes, taking into account the lane boundaries. When it comes to making decisions around changing lanes, the in-vehicle control computer 150 may prioritize safety over regulation and over efficiency. The in-vehicle control computer 150 may categorize lane change intentions based on safety, regulatory, and efficiency concerns, unless otherwise specified. In some embodiments, the priority order may be as follows from the highest priority to the lowest priority, critical safety, non-critical safety, regulatory, efficiency, precautionary, and preference. For example, in FIG. 5CU is a photo showing four lanes available to drive in the direction and two lanes prohibiting entrance. In some embodiments, the in-vehicle control computer 150 may plan a lane selection among the drivable lanes. FIG. 5CV also shows multiple lanes, but the lanes the in-vehicle control computer 150 may choose are limited by the dynamic barrier.

In some embodiments, the autonomous vehicle 105 is a truck. The in-vehicle control computer 150 evaluates if the available lanes permit trucks to complete the route, based on dynamic zone signs. The in-vehicle control computer 150 may consider the type of cargo, load and braking capabilities it has before planning a lane change.

The in-vehicle control computer 150 may check if the available lane is for passing vehicles in front or can be used to continue the planned mission.

When changing lane in a dynamic zone, the autonomous vehicle 150 may perform lane change according to regulatory lane change intention following the priority model defined.

Fixed Zones

The map defines fixed zones as areas or roads within a predetermined distance, e.g., 100 meters, 200 meters, or 300 meters, from a hospital, a fire station, or an airport. In these fixed zones, there is a higher probability to encounter special vehicles, e.g., emergency vehicles.

The in-vehicle control computer 150 on the autonomous vehicle 105 detects a fixed zone before entering it. In some embodiments, the in-vehicle control computer 150 tries to identify the fixed zones by retrieving data from the stored map. In some embodiments, the in-vehicle control computer 150 detects the traffic signs relevant to the fixed zones.

An emergency-signal-ahead sign is the most common sign that is used to alert road users to fixed zones, i.e., locations where unexpected entries into the roadway by emergency vehicles may occur. The emergency-signal-ahead sign is typically placed below an emergency vehicle sign. The emergency vehicle sign with the emergency-signal-ahead sign supplemental plaque may be placed in front of all emergency-vehicle traffic control signals. The emergency vehicle sign, or a word message sign indicating the type of emergency vehicle, Such as a rescue squad, may be used in front of an emergency-vehicle station when no emergency-vehicle traffic control signal is present. An emergency medical services symbol sign may be used to identify medical service facilities that are included in the emergency medical services system. The emergency medical service symbol sign may be used above a hospital sign or a hospital symbol sign or above a sign with a legend ambulance station or an emergency-medical-care sign. The in-vehicle control computer 150 may use these signs to detect a hospital zone as one of the fixed zones.

Guide signs for commercial service airports and non-carrier airports may be installed in interstate freeways, other freeways, or conventional highway intersections connected to an airport, normally less than 15 miles from the airport. The airport symbol sign along with a supplemental plaque may be used to indicate the specific name of the airport. An airport symbol sign, with or without a supplemental name plaque or the word airport together with an arrow may be used as a trailblazer. Adequate trailblazer signs may be in place prior to installing the airport guide signs.

Various types of fixed zone signs are shown in FIG. 5CW-5BD as examples.

The autonomous vehicle 105 may navigate through and pass fixed zones autonomously and safely.

In a hospital fixed zone, the autonomous vehicle 105 may drive at a predetermined speed that is lower than the posted speed limit for the area, e.g., 5 mph, 10 mph, or 15 mph below the posted speed limit. The autonomous vehicle 105 may drive in the right lane and be ready to pull-over once an emergency vehicle is present. The autonomous vehicle 105 can avoid using its horn in hospital zones.

In a fire station fixed zone, the autonomous vehicle 105 may drive at a predetermined speed that is lower than posted speed limit for the area, e.g., 10 mph, 15 mph, 20 mph, or 25 mph below the posted speed limit. The autonomous vehicle 105 may drive in the right lane and be ready to pull-over if an emergency vehicle is present.

In an airport fixed zone, the autonomous vehicle 105 may avoid driving in the exit lanes.

High Luminosity Change

High luminosity change is defined in the digital map that is stored in the memory 175 of the in-vehicle control computer 150 as a sudden change in luminosity by a predetermined amount, e.g., by over 75 times, over 100 times, or over 125 times.

High luminosity change, or the sudden change in luminosity may happen in a few different ways, for example, in light transition areas, from sun glare, or from oncoming traffic headlights.

The map is developed with the intention to include locations of light transition areas, including when exiting from a lighted street or road and moving to a dark street or road, or the opposite, when entering a tunnel, and when exiting a tunnel. FIG. 5DC shows a lighted street, and FIG. 5DD shows a lighted tunnel.

The in-vehicle control computer 150 actively detects light transition areas from a predetermined distance away, e.g., from 100 meters, 150 meters, 175 meters, 200 meters, or 225 meters away.

In addition to light transition areas, the in-vehicle control computer 150 also actively detect high luminosity change.

Grade Difference Merge

Entry ramp (e.g., on-ramp) and exit ramp (e.g., off-ramp) are ramps that allow vehicles to enter or to exit a roadway or to change for one roadway to another. The map stored in the memory 175 of the in-vehicle control computer 150 intends to keep entry and exit ramp information, including ramp type, e.g., entry or exit, ramp class, the remaining distance to the ramp, the maximum ramp speed, and etc.

The in-vehicle control computer 150 considers entry ramp classes as parallel acceleration lane or tapered acceleration lane. The last part of a parallel lane entry is parallel to traffic on the roadway the vehicle intends to enter. This part of the ramp is also called an acceleration lane. On the other hand, a tapered lane entry doesn’t have a parallel part to the traffic. Example entry ramps are schematically illustrated in FIG. 5DE and FIG. 5DF.

The in-vehicle control computer 150 may consider exit ramp classes as parallel deceleration lane, tapered deceleration lane, or exit only lane. FIG. 5DG-5DI schematically illustrate three example exit ramps.

The map stored on the in-vehicle control computer 150 also intends to keep information about the presence of a cloverleaf ramp and its attributes, e.g., the remaining distance to the ramp, the maximum ramp speed, the length of the white line break for the ramp, and etc. A cloverleaf ramp is a kind of entry and exit ramp in one lane. As shown in FIG. 5DJ as an example, a cloverleaf ramp is an entry ramp from the bottom side of the figure, and it evolves to an exit ramp when reaching at the top. A cloverleaf ramp is also called a K-ramp.

The in-vehicle control computer 150 of the autonomous vehicle 105 actively detects road markings and traffic signs to identify ramps and their classes. A ramp traffic sign is shown in FIG. 5DK as an example. In the embodiments that the in-vehicle control computer 150 detects an unmapped ramp or absence of mapped ramp, the in-vehicle control computer 150 may inform the oversight system 350 to update the map.

In some embodiments, when a ramp is identified, the in-vehicle control computer 150 develops actions according to pre-developed plans. When the autonomous vehicle 105 is in the right lane on a highway approaching a tapered acceleration lane entry ramp or a parallel acceleration lane entry ramp, the in-vehicle control computer 150 may perform a non-critical lane change the lane to the left, if possible, to avoid any vehicle from the entry ramp. If the autonomous vehicle 105 is in a lane that an oncoming vehicle from an entry ramp is merging into and the vehicle’s bumper is head of the autonomous vehicle 105, the in-vehicle control computer 150 may dynamically adjust the autonomous vehicle 105′s speed to allow the vehicle from the entry ramp to merge into the lane.

If the autonomous vehicle 105 is in a tapered lane entry ramp, the in-vehicle control computer 150 may yield to a vehicle in the lane where the autonomous vehicle 105 is merging into when the vehicle’s bumper is ahead of the bumper of the autonomous vehicle 105. In some embodiments, if the autonomous vehicle 105 is in a tapered lane entry ramp, it may stop if the time to collision (TTC) is less than a predetermined length of time, e.g., 5 seconds, 6 seconds, 7 seconds, 8 seconds, or 9 seconds, with a vehicle in the roadway lane where the autonomous vehicle 105 is merging into.

When another vehicle is in a parallel lane entry ramp and is trying to merge into a lane that the autonomous vehicle 105 is in before the end of the acceleration lane, if that vehicle’s bumper is ahead of the autonomous vehicle 105′s bumper, the in-vehicle control computer 150 may dynamically adjust its speed to allow the other vehicle from the entry ramp to merge into the lane. The in-vehicle control computer 150 may estimate suitable gap available behind the vehicle before merging. The in-vehicle control computer 150 may merge with the vehicle before the end of acceleration lane but after being in parallel with the it. See FIG. 5DL which schematically shows an example.

When the autonomous vehicle 105 is in a zipper merge lane, after crossing the ramp meter lights, the in-vehicle control computer 150 may adjust its speed, while respecting the ramp speed limit, in the ramp meter lane so that it can find sufficient lateral gap to merge into the freeway lane. Getting sufficient lateral gap allows the autonomous vehicle 105 to merge in the intended lane and yield to other vehicles whose bumper is ahead of the autonomous vehicle 105′s.

In some embodiments, the autonomous vehicle 105 may activate its turn lights according to the on or off ramp position when it is entering into or exiting from the lane.

When the autonomous vehicle 105 is in an exit ramp lane but does not intend to take the exit ramp, the in-vehicle control computer 150 may dynamically adjust the speed to make a non-critical lane change at least a predetermined distance, e.g., 75 meters, 100 meters, or 125 meters, ahead of exit ramp. In other words, the autonomous vehicle 105 may change the lane if its current lane is an exit only lane.

In some embodiments, if the autonomous vehicle 105 intends to take an exit ramp, the in-vehicle control computer 150 may plan to get into the lane that merges into the deceleration lane or the exit lane of the exit ramp. The autonomous vehicle 105 may enter in the deceleration lane at the beginning. FIG. 5DM schematically shows an example of taking an exit ramp. When the exit ramp is a tapered or parallel exit ramp, the in-vehicle control computer 150 may plan to decelerate to enter the exit ramp as indicated in mapped data or detected traffic sign.

When the autonomous vehicle 105 goes through an overleaf ramp section, the in-vehicle control computer 150 may identify whether a vehicle coming from the adjacent lane intends to merge in the lane the autonomous vehicle 105 is current lane. The autonomous vehicle 105 may yield if the bumper of the oncoming vehicle in that lane is ahead of the autonomous vehicle 105′s bumper. In case the autonomous vehicle 105 intends to take the next overleaf exit ramp, it may make a non-critical lane change to take the lane that merges into overleaf exit ramp.

The autonomous vehicle 105 may detect if the turn lights of the vehicles in adjacent overleaf entry ramp are activated to merge in current lane of the autonomous vehicle 105.

When the autonomous vehicle 105 is in an overleaf entry ramp, the in-vehicle control computer 150 may activate turn lights and dynamically adjust the speed to find sufficient lateral gap to make a non-critical lane change to continue its mission. If the autonomous vehicle 105 intends to take the overleaf exit ramp, it may continue to drive on the lane that merge in exit ramp lane.

When the autonomous vehicle 105 approaches a curved ramp, the in-vehicle control computer 150 may retrieve information about the curved ramp from the map, including information about curvature, curvature angle and gradient of the curved ramp. The in-vehicle control computer 150 may plan to slow down to enter the curved ramp lane at a speed that is lower than the speed limit by a predetermined percentage, e.g., 10%, 15% lower, or 20% lower. And the in-vehicle control computer 150 may adjust the speed dynamically to have lateral acceleration no more than a predetermined value, e.g., 1.5 m/s², 2 m/s², or 2.5 m/s².

Example Technique for Operating an Autonomous Vehicle on a Roadway With a Grade

One objective of this disclosure includes controlling an autonomous vehicle 105 on the roadway has a grade. FIG. 5DN illustrates an example method which can be used to control the autonomous vehicle 105 based on the detected roadway data and mapped data. The method 550 may be described herein as being performed by one or more processors, which may include the in-vehicle control computer 150.

The method 550 begins at block 552. At block 554, the in-vehicle control computer 150 is configured to receive detected roadway conditions data including roadway grade data from the at least one perception sensor on the autonomous vehicle 105.

At block 556, the in-vehicle control computer 150 is configured to retrieve the mapped data having roadway grade data from the non-transitory computer readable medium on the in-vehicle control computer of the autonomous vehicle 105.

At block 558, the in-vehicle control computer 150 is configured to determine that the roadway has a grade based on the detected roadway grade data and the retrieved mapped roadway grade data.

At block 560, in response to the determining that the roadway has a grade, the in-vehicle control computer 150 is configured to determine that the grade of the roadway is greater than or equal to a predetermined high grade value and less than a predetermined grade limit.

At block 562, in response to the determining that the grade of the roadway is greater than or equal to a predetermined high grade value and less than a predetermined grade limit, the in-vehicle control computer 150 is configured to operate the autonomous vehicle to change its lane to the right-most lane. Then the method comes to an end 564.

Environmental Conditions

The environmental conditions under which an autonomous vehicle 105 is operating can greatly affect how safe certain maneuvers will be during navigation. Thus, it is desirable for the autonomous vehicle 105 to obtain accurate information regarding the current and/or future environmental conditions which the autonomous vehicle 105 may encounter while traversing a route.

Environmental conditions, such as inclement weather, may include various environmental conditions that can negatively affect the ability of the autonomous vehicle 105 to continue safely navigating along its defined route. When the environmental conditions are sufficiently severe, the autonomous vehicle 105 may not be able to safely continue navigation. In such conditions, the autonomous vehicle 105 can determine to pull over to the side of the roadway or otherwise cease navigation for the safety of the autonomous vehicle 105 as well as other entities on or near the roadway. In the particular embodiment of an autonomous truck 105, it can take a significant amount of time to perform maneuvers such as stopping, changing lanes, and swerving to avoid obstacles during different types of inclement weather or other environmental conditions. Thus, it is desirable for the autonomous vehicle 105 to be able to react to changing environmental conditions before the conditions become severe enough such that the autonomous vehicle 105 determines to cease continued navigation for safety.

There are a number of aspects related to the autonomous vehicle’s 105 ability to sense and respond to environmental conditions, including the detection of inclement conditions, operation of the autonomous vehicle 105 when outside of an ODD, detection of icy roads, response to road traction conditions, and operational limits of the autonomous vehicle 105 to road water conditions.

In certain embodiments, the in-vehicle control computer 150 of the autonomous vehicle 105 described herein can address at least some of the above described problems by receiving perception data from at least one perception sensor of the autonomous vehicle 105, receiving an indication of current weather conditions from an external weather condition source, determining a current environmental condition severity level from a plurality of severity levels based on the perception data and the indication of current weather conditions, modifying one or more driving parameters that govern a range of actions that can be autonomously executed by the autonomous vehicle 105, and navigating the autonomous vehicle 105 based on the modified driving parameters. The range of actions can include any actions that the autonomous vehicle 105 may take in response to the determined environmental condition severity level, including an MRC maneuver, slowing down, activating headlights, avoiding lane changes, avoiding lane biasing, etc.

Inclement Weather

Inclement weather may include various environmental conditions typically caused by weather conditions that can negatively affect the ability of the autonomous vehicle 105 to continue safely navigating along its defined route. In certain embodiments, the in-vehicle control computer 150 can be configured to receive information from a variety of sources including the vehicle sensor subsystems 144 and the oversight system 350 to determine whether the environmental conditions are indicative of inclement weather than may affect the ability of the autonomous vehicle 105 to continue along its current or defined route. In some embodiments, the in-vehicle control computer 150 can receive a periodically updated map that includes the latest weather information and/or warning, for example, from the oversight system 350. In some embodiments, the periodically updated map may be continuously updated to include the latest weather information and/or warnings. FIGS. 6A and 6B illustrate example visualizations of the periodically updated map in accordance with aspects of this disclosure.

In some embodiments, the in-vehicle control computer 150 can be configured to determine which of a plurality of levels of severity corresponds to the environmental conditions. For example, the in-vehicle control computer 150 can be configured to assign the environmental conditions to one of the following levels of severity: normal, degraded, cautionary, and critical. However, aspects of this disclosure are not limited thereto and the in-vehicle control computer 150 can be configured to assign the detected environmental conditions to a greater or fewer number of severity levels.

As used herein, a normal weather condition (e.g., a normal environmental severity) may generally refer to weather or environmental conditions that do not impair any of the autonomous vehicle’s 105 Ego’s visibility, traction, and stability levels.

As used herein, a degraded weather condition (e.g., a degraded environmental severity) may generally refer to any inclement weather or environmental conditions that contain a degraded visibility level, a degraded traction level, and/or a degraded stability level.

As used herein, a cautionary weather condition (e.g., a cautionary environmental severity) may generally refer to any inclement weather or environmental conditions that contain a cautionary visibility level, a cautionary traction level, and/or a cautionary stability level.

As used herein, a critical weather condition (e.g., a critical environmental severity) may generally refer to any inclement weather or environmental conditions that are out of ODD and are no longer safe for the autonomous vehicle 105 to continue operations. The autonomous vehicle 105 may receive a warning indicating a critical weather condition by, for example, the US weather service.

In some embodiments, the in-vehicle control computer 150 can receive an indication of a severe and/or critical environmental condition from an external source, such as the United States Weather Service or other external source. As used herein, wireless emergency alerts (WEA) may generally refer to emergency messages sent by an authorized government alerting authorities through the autonomous vehicle’s 105 network communications subsystem 178.

In certain embodiments, the in-vehicle control computer 150 can be configured to execute an MRC maneuver as soon as possible in response to receiving an indication that the environmental conditions are critical from the external source. Examples of critical environmental conditions include tornados and other extreme weather events where no vehicles should be operating except for rescue workers.

In response to determining that the autonomous vehicle 105 should execute an MRC maneuver, the in-vehicle control computer 150 can be configured to perform a first MRC maneuver (e.g., pulling over to a shoulder of the roadway). The first MRC maneuver may be safer than other MRC maneuvers for both the autonomous vehicle 105 and other entities on or near the roadway.

In some embodiments, in response to receiving an indication of a critical environmental condition from the external source, the in-vehicle control computer 150 can be configured to prepare to execute an MRC maneuver and inform the oversight system 350 to request a final decision. The received critical environmental condition can indicate that the weather condition is occurring within a defined radius of the autonomous vehicle 105. The oversight system 350 may make a final decision regarding any actions to be taken by the autonomous vehicle 105 in response to the received critical environmental condition.

The in-vehicle control computer 150 can also be configured to assign a separate level of severity to each of a plurality of driving conditions including one or more of the following: road traction, visibility, and stability. The in-vehicle control computer 150 can determine an overall environmental condition severity level based on a combination of the levels of severity for each of the driving conditions. In some embodiments, the memory 175 can store a matrix that relates each combination of the levels of severity for each of the driving conditions to a corresponding overall environmental condition severity level. That is, each combination of the levels of severity for each of the driving conditions may have a different cumulative effect on the ability of the autonomous vehicle 105 to continue safely navigation, and thus, the matrix can provide an accurate assessment of the severity of the current environmental conditions/inclement weather.

In some embodiments, a degraded stability level can be measured by detecting an uncontrolled deviation from the center of the autonomous vehicle’s 105 lane at a standard bias level. In some embodiments, a degraded stability level can generally refer to a degraded weather condition that causes impairment to the autonomous vehicle’s 105 stability due to inclement weather where the autonomous vehicle 105 is still within ODD.

The in-vehicle control computer 150 can also be configured to modify the behavior and speed of the autonomous vehicle 105 to respond to inclement weather that contains degraded stability levels. In some embodiments, the in-vehicle control computer 150 is configured to receive weather reports from the oversight system 350. The in-vehicle control computer 150 can also detect present weather conditions via one or more of the sensors of the vehicle sensor subsystems 144.

During a degraded stability level, in certain embodiments, the in-vehicle control computer 150 can be configured to cause the autonomous vehicles 105 to perform one or more of the following: lane biasing, MRC maneuvers, and/or a lane change.

The in-vehicle control computer 150 can also detect a degraded stability level in response to detecting one or more of the following conditions: changes in wind conditions, and degradation of the autonomous vehicle’s 105 stability level due to a change in weather.

In response to detecting a degraded stability level, the in-vehicle control computer 150 can be configured to slow the autonomous vehicle 105 to a safer speed, and avoid lane changes and lane biases unless either one is necessary. Under degraded stability levels, the in-vehicle control computer 150 can be configured to, if safe to do so, lane change to the right-most lane and inform the oversight system 350 of the degraded weather response.

In one example scenario, the in-vehicle control computer 150 can be configured to detect a change in stability that dictates a degraded weather response. In response, the in-vehicle control computer 150 can be configured to reduce the speed of the autonomous vehicle 105 to ensure a stopping distance with the maximum available deceleration rate always remains available. The in-vehicle control computer 150 can be configured to refrain from making any lane changes except with critical intent. The in-vehicle control computer 150 can be configured to refrain from lane biasing the autonomous vehicle 105 except to avoid collisions. The in-vehicle control computer 150 can be configured to lane change to the right-most lane (or left-most lane when in a left-hand drive region), if it is safe to do so.

The in-vehicle control computer 150 can be configured to detect a cautionary stability level by measuring an uncontrolled deviation from the center of the autonomous vehicle’s 105 lane at a maximum bias within the lane level. As used herein, a cautionary stability level generally refers to a cautionary weather condition or environmental condition that causes impairment to the autonomous vehicle’s 105 stability due to inclement weather and is at risk of becoming out of ODD.

The in-vehicle control computer 150 can be configured to detect a cautionary stability level in response to the autonomous vehicle 105 modifying its behavior and speed to response to inclement weather that contains cautionary stability levels. In particular, in-vehicle control computer 150 can be configured to detect a cautionary stability level in response to one or more of the following conditions: detecting a change in weather conditions, the autonomous vehicle’s 105 stability level is impaired to cautionary levels as driven by a change in weather that may place the autonomous vehicle 105 in an out-of-ODD situation.

During a cautionary stability level, the in-vehicle control computer 150 can be configured to lane bias, perform an MRC maneuver, and/or perform a lane change.

In response to detecting a cautionary stability level, the in-vehicle control computer 150 can be configured to perform one or more of the following actions: slow the autonomous vehicle 105 to safer speeds, avoids lane changes and lane biases unless either are absolutely necessary, and lane change to the right-most lane.

In one example scenario, the in-vehicle control computer 150 can be configured to detect a change in stability that dictates a cautionary weather response. In response, the in-vehicle control computer 150 can be configured to execute lane change maneuvers to the right-most lane for the duration of any cautionary weather. The in-vehicle control computer 150 can also be configured to activates emergency lights until the cautionary weather conditions have concluded. The in-vehicle control computer 150 can be configured to avoids all lane changes, except for those that are required for safety (e.g., lane change to the right-most lane) or those required to continue the current mission (e.g., to take an exit to stay on route). If the autonomous vehicle 105 must lane change, the in-vehicle control computer 150 can be configured to use a critical lane change. The in-vehicle control computer 150 can further be configured to use lane biases to avoid collision.

If the in-vehicle control computer 150 detects degraded visibility and degraded traction level simultaneously, the in-vehicle control computer 150 can be configured to reduce the speed of the autonomous vehicle 105 to ensure a stopping distance with the maximum available deceleration rate remains available. In response to detecting degraded stability levels or degraded traction levels, the in-vehicle control computer 150 is configured to refrain from any lane changes except when with critical intent. In response to detecting degraded visibility levels, the in-vehicle control computer 150 can refrain from making any changes except for with critical intent if a target back critical distance behavior can be confirmed. In some embodiments, confirmation of the target back critical distance behavior can include detecting and localizing vehicles behind the autonomous vehicle 105 that are in a target lane that the autonomous vehicle 105 is intending to lane change or maneuver into. These detected vehicles may correspond to the vehicles that autonomous vehicle 105 we will be cutting in front of if the lane change is executed. The in-vehicle control computer 150 can be configured to verify that the detected vehicles meet one or more conditions for distance and relative velocity in order for the autonomous vehicle 105 to perform the lane change. When the in-vehicle control computer 150 has determined that there is decreased visibility (e.g., detecting degraded visibility levels), the in-vehicle control computer 150 can determine whether it would be safe to make the lane change if a vehicle is at the threshold of the rear visibility of the autonomous vehicle 105 and the vehicle is driving the speed limit. In response to determining that it would be safe to make a lane change under these conditions, the autonomous vehicle 105 can control the autonomous vehicle 105 to execute the lane change.

If the in-vehicle control computer 150 detects degraded traction levels, the in-vehicle control computer 150 can be configured to apply the maximum available deceleration rate or less to decelerate. If the in-vehicle control computer 150 detects degraded traction levels or degraded stability, the in-vehicle control computer 150 can be configured to lane bias to avoid collision. If safe to do so, the in-vehicle control computer 150 can be configured to lane change to the right-most lane.

The in-vehicle control computer 150 can also be configured to perform a set of standard actions in response to detecting any type of degraded environmental conditions. For example, the in-vehicle control computer 150 can be configured to: execute lane change maneuvers to the right-most lane for the duration of any inclement weather, activate the autonomous vehicle’s 105 emergency lights until the cautionary weather conditions have concluded, avoid all lane changes, except for those that are required for safety (e.g., lane change to the right-most lane) or those required to continue the autonomous vehicle’s 105 mission (e.g., to take an exit), use a critical lane change if a lane change is required, and apply the maximum available deceleration rate or less to decelerate.

The in-vehicle control computer 150 can also be configured to perform a set of standard actions in response to detecting any type of critical environmental conditions. For example, the in-vehicle control computer 150 can be configured to, in response to detecting a sudden and extreme (as defined by the US weather service) change in weather that is determined to be out-of-ODD (e.g., sudden tornado) or in response to receiving a US Weather service Bulletin warning of imminent extreme weather in ego’s immediate path, the in-vehicle control computer 150 can activate its emergency lights, determine the proper MRC maneuver to conduct, execute the proper MRC maneuver, and enter a safe state to protect itself during the extreme weather event and keep hazard lights on for visibility.

The in-vehicle control computer 150 can also be configured to perform a set of standard actions in response to detecting both traction and stability cautionary environmental conditions. For example, the in-vehicle control computer 150 can detect a change in traction and stability that dictates a cautionary weather response. In response, the in-vehicle control computer 150 can perform one or more of the following actions: execute lane change maneuvers to the right-most lane for the duration of any cautionary weather, activates the autonomous vehicle’s 105 emergency lights until the cautionary weather conditions have concluded, reduces the autonomous vehicle’s 105 speed to ensure a stopping distance with maximum available deceleration rate always remains available, avoids all lane changes, except for those that are required for safety (e.g., lane change to the right-most lane) or those required to continue the autonomous vehicle’s mission (e.g., to take an exit), if the autonomous vehicle must lane change, the in-vehicle control computer 150 can use critical lane change, the autonomous vehicle 105 applies the maximum available deceleration rate or less to decelerate, and lane biases to avoid collision.

The in-vehicle control computer 150 can also be configured to provide some or all of the data collected regarding the environmental conditions to the oversight system 350, for example, via the network communications subsystem 178. In some embodiments, the in-vehicle control computer 150 can provide the level of severity determined for each of the driving conditions as well as the corresponding location. The oversight system 350 may update the continuously updated map in part based on the information regarding the environmental conditions received from one or more autonomous vehicles 105 in a fleet.

One example driving condition that the in-vehicle control computer 150 can track is the severity level of road traction. In some embodiments, the in-vehicle control computer 150 can detect the road traction level based on the current weather and/or the current temperature. In addition, the continuously updated map can also include data representative of the road traction for at least a portion of the roadways in the map. Additional details regarding the detection and evaluation of road traction are provided in the road traction subsection. In some embodiments, the autonomous vehicle 105 is configured to operate autonomously when the ambient air temperature is between -12° C. and 40° C.

Another example driving condition that the in-vehicle control computer 150 can track is the severity level of visibility. In particular, the in-vehicle control computer 150 can determine the visibility distance ahead of the autonomous vehicle 105, for example, based on images obtained using a camera and/or other sensors of the vehicle sensor subsystems 144. The in-vehicle control computer 150 can control the autonomous vehicle 105 to adjust its speed so as to maintain a time to collision (TTC) (e.g., the amount of time until the autonomous vehicle 105 reaches the current visibility distance) that is greater than a threshold time. In one example, the threshold time may be at least six seconds, however, the threshold time may be longer or shorter depending on the particular implementation.

Example environmental conditions that can affect visibility include snow and/or fog. Thus, the in-vehicle control computer 150 can determine whether the current environmental conditions are indicative of snow or fog based on: the continuously updated map and/or data received from one or more of the sensors of the vehicle sensor subsystems 144. In response to determining that the autonomous vehicle 105 is experiencing environmental conditions that can affect visibility, the in-vehicle control computer 150 can determine the visibility distance as discussed above and control the autonomous vehicle 105 to maintain a TTC threshold time. In addition, the in-vehicle control computer 150 can determine a severity level of the visibility conditions and use the determined severity level as an input in determining an overall severity level as discussed above.

In some embodiments, the autonomous vehicle 105 is configured to operate autonomously when the visible distance can satisfy one or more the following conditions: the autonomous vehicle 105 can maintain the visibility of 8 seconds or greater, given its current speed, and the autonomous vehicle 105 cannot slow down more than ⅔ of the posted speed limit (e.g., 50 mph in a 75 mph zone). The in-vehicle control computer 150 can be configured to maintain the autonomous vehicle’s 105 visibility speed minimum to be independent of traction conditions.

The in-vehicle control computer 150 can further be configured to take different actions based on determining the presence and severity of one or more environmental conditions, such as rain, snow, constant wind, and/or wind gusts.

In some embodiments, the in-vehicle control computer 150 is configured to operate the autonomous vehicle 105 in rain conditions when accumulations do not equal to or exceed 0.01 inch per hour. The in-vehicle control computer 150 can further be configured to operate in snow conditions when accumulations do not equate to or exceed 0.01 inch per hour. The in-vehicle control computer 150 can also be configured to operate under constant wind speeds that do not exceed or equate to 23 MPH and within conditions of wind gusts whose speeds do not exceed or equate to 30 MPH. Of course these values are only exemplary and do not limit the disclosure.

As used herein, a wind gust generally refers to a brief increase in speed of the wind. According to U.S. weather observing practice, gusts are reported when the peak wind speed reaches at least 16 knots and the variation in wind speed between the peaks and lulls is at least 9 knots. The duration of a gust is usually less than 20 seconds.

The in-vehicle control computer 150 can control the autonomous vehicle 105 to take a combination of different actions in response to determining that the autonomous vehicle 105 has entered a region experiencing inclement weather. One such action is a lane change. When the in-vehicle control computer 150 determines that the environmental conditions include inclement weather (e.g., any one of the levels of severity for each of the driving conditions is higher than normal), the in-vehicle control computer 150 may avoid changing lanes for reasons other than ensuring the safety of the autonomous vehicle 105 or other entities on or near the roadway. For example, the in-vehicle control computer 150 may avoid controlling the autonomous vehicle 105 to change lanes for regulatory, efficiency, and/or precautionary reasons. The in-vehicle control computer 150 can further be configured to control the autonomous vehicle 105 to perform a lane change in order to maintain the safety of the autonomous vehicle 105 and/or another entity on or near the roadway.

The in-vehicle control computer 150 can also be configured to adjust a lane bias of the autonomous vehicle 105 based on the determined levels of severity for each of the driving conditions and/or the overall level of severity for the environmental conditions. As used herein, lane bias may refer to the lateral positioning of the autonomous vehicle 105 within a lane. For example, during normal environmental conditions, the in-vehicle control computer 150 can control a lane bias of the autonomous vehicle 105 to, for example, avoid obstacles within its current lane, to communicate intention to other entities on or near the roadway, etc. During inclement weather conditions (e.g., when at least one of the driving conditions has a level of severity other than normal or at a different threshold), the in-vehicle control computer 150 can avoid performing lane bias unless lane biasing the autonomous vehicle 105 would help avoid a potential collision. By avoiding lane biasing, the autonomous vehicle 105 may have increase a buffer within the lane to respond to the inclement weather (e.g., wind may push the autonomous vehicle 105 away from the center of the lane).

The in-vehicle control computer 150 can also adjust the control of the autonomous vehicle 105 when inclement weather is detected based on the shape of the roadway. For example, when the autonomous vehicle 105 is approaching or on a curve in the roadway during inclement weather, the in-vehicle control computer 150 can adjust the speed of the autonomous vehicle 105 such that lateral acceleration of the autonomous vehicle 105 is less than a predetermined value. Depending on the embodiment, the predetermined value may be 1.5 m/s2, 2 m/s², or 2.5 m/s2, although other threshold values are also possible. The in-vehicle control computer 150 can determine lateral acceleration of the autonomous vehicle 105 based on the current trajectory and speed of the autonomous vehicle 105 and/or by directly measuring lateral acceleration using a sensor (e.g., an IMU) of the vehicle sensor subsystem 144.

The in-vehicle control computer 150 can also take certain actions when approaching a bridge during inclement weather. For example, when the in-vehicle control computer 150 determines that the autonomous vehicle 105 is approaching a bridge and the outside temperature is less than a threshold value (e.g., less than 3° C., less than 4° C., less than 5° C. although other values are also possible), the in-vehicle control computer 150 can adjust the speed of the autonomous vehicle 105 such that the autonomous vehicle 105 arrives at the bridge at a speed that is a predetermined amount slower than the speed limit. In some embodiments, the predetermined speed at which the autonomous vehicle 105 arrives at the bridge is for example, 7%, 10%, or 15% slower that the speed limit. In other embodiments, the predetermined speed at which the autonomous vehicle 105 arrives at the bridge can be a set amount lower than the speed limit (e.g., 5 mph or 10 mph slower than the speed limit). The in-vehicle control computer 150 can further dynamically adjust the speed of the autonomous vehicle 105 when arriving at or traversing a bridge, for example, in response to determining that the autonomous vehicle 105 is not maintaining its lateral position within the lane due to the slippery environmental conditions on the bridge.

The in-vehicle control computer 150 can, in response to detecting inclement weather, also be configured to determine whether the road traction of the autonomous vehicle 105 is withing a predetermined range of values (e.g., less than 0.8 but greater than 0.5, less than 1.0 but greater than 0.4, etc.). In response to determining that the road traction is within the predetermined range, the in-vehicle control computer 150 can be configured to adjust the speed of the autonomous vehicle 105 to a predetermined speed (e.g., 15 mph, 20 mph, 25 mph).

Out of Operational Design Domain (ODD)

One aspect related to the detection of environmental conditions and safely navigating the autonomous vehicle 105 based on the detected environmental conditions is the ODD of the autonomous vehicle 105. As used herein, ODD generally refers to a set of specific conditions under which the autonomous vehicle 105 is designed to function. Thus, one aspect of safely operating an autonomous vehicle 105 is to be able to detect whether the autonomous vehicle 105 is within the ODD. In order to ensure that the autonomous vehicle 105 does not cause or become involved in any collisions, the autonomous vehicle 105 can also be configured to take certain actions when the autonomous vehicle 105 detects that it is outside of the ODD.

In some implementations, the in-vehicle control computer 150 is configured to cause the autonomous vehicle 105 to perform an MRC maneuver when an out-of-ODD weather condition is encountered. For example, because the autonomous vehicle 105 is not designed to operate in ODD conditions, the in-vehicle control computer 150 is configured to enter a safe state to prevent harm to road users or property.

According to certain embodiments, the ODD of the autonomous vehicle 105 can be classified into three categories: 1. In ODD, 2. Degraded ODD, and 3. Out of ODD. The in-vehicle control computer 150 of the autonomous vehicle 105 can be configured to perform certain actions based on which ODD level the autonomous vehicle 105 is currently experiencing. Depending on the embodiment, the in-vehicle control computer 150 can be configured to determine which ODD level the autonomous vehicle 105 is currently experiencing at least in part on thresholds for ice, rain, fog, wind, and/or weather conditions. For example, in ODD may refer to no detriment to any of the above-listed conditions, degraded ODD may refer to a detriment to one of more of the above-listed conditions but the autonomous vehicle 105 is still within ODD, and out of ODD may refer to passing one or more of the above thresholds such that it is no longer safe to operate the autonomous vehicle 105.

One action that the autonomous vehicle 105 can take in response to being out of ODD is an MRC maneuver. Depending on the implementation, the autonomous vehicle 105 may be configured to take one of a plurality of different MRC maneuvers (e.g., a first MRC maneuver may include pulling over to a shoulder of the roadway, a second MRC maneuver may include a full brake while staying in the current lane, and a third MRC maneuver may include smooth braking while staying in the current lane). After executing the first MRC maneuver, the autonomous vehicle 105 may be in a safe state. As used herein, a safe state generally refers to the condition after the autonomous vehicle 105 is stationary off the drivable roadway and will remain stationary until further notice or direction from the oversight system 350.

The in-vehicle control computer 150 may store a map within the memory 175 that includes a map of the roadways and nearby environment (see the Map Taxonomy section of this application). The map can include safe zones for which it can be safe for the autonomous vehicle 105 to perform MRC maneuvers. FIGS. 6C and 6D illustrate example visualizations of the safe zones on or near the roadway in accordance with aspects of this disclosure.

In some embodiments, the in-vehicle control computer 150 can be configured to control the autonomous vehicle 105 to perform the first MRC maneuver (e.g., pulling over to a shoulder of the roadway) in response to determining that the ODD level is “Out of ODD.” The in-vehicle control computer 150 may also consider whether the map indicates that a safe zone is available prior to executing the first MRC maneuver.

In some embodiments, the in-vehicle control computer 150 can be configured to control the autonomous vehicle 105 to perform the third MRC maneuver (e.g., smooth braking while staying in the current lane) in response to the autonomous vehicle 105 attempting to perform the first MRC maneuver for longer than a predetermined period of time without success. Depending on the embodiment, the predetermined period of time may be 2 minutes, however, shorter or longer predetermined periods of time can also be used.

The in-vehicle control computer 150 can also be configured to notify the oversight system 350 in response to determining that the ODD level is “Out of ODD.” The notification can include an indication of the location, time, and/or an event trigger associated with the ODD. The event trigger can include, for example, the environmental conditions for at least the length of time in which the autonomous vehicle 105 was in the “Out of ODD” level.

Icy Road Detection

One environmental condition that the in-vehicle control computer 150 can be configured to monitor and detect is whether any portion of the roadway is in an icy condition. In some embodiments, the in-vehicle control computer 150 can be configured to detect traffic signs indicating the warning of an icy road at a predetermined minimum distance in front of the autonomous vehicle 105. Depending on the implementation, the predetermined minimum distance may be, for example, 200 m, 222 m, 250 m, 275 m, 300 m, however, other predetermined distances are also possible. In some embodiments, the autonomous vehicle 105 can be configured to operate autonomously when the coefficient of friction is greater than or equal to 0.5. FIGS. 6E-6G illustrate example visualizations of traffic signs that may identify icy conditions in accordance with aspects of this disclosure.

The in-vehicle control computer 150 may store a map within the memory 175 that includes a map of the roadways and nearby environment (see the Map Taxonomy section of this application). The map can include the locations of roadways and/or roadway areas which have at least a predetermined probability of becoming icy. For example, the locations indicative of icy roadways can include any roadways for which icy road signage is present as well as any roadways which have been detected by an autonomous vehicle 105 in the fleet as having been icy in the past.

The in-vehicle control computer 150 can also be configured to detect any snow and/or sleet accumulation in the roadway as well as the amount of accumulation, for example, using one or more of the sensors of the vehicle sensor subsystems 144. In response to determining that the snow and/or sleet accumulation is less than a threshold depth and determining that the coefficient of friction between the roadway and the autonomous vehicle 105 is greater than a threshold coefficient of friction, the in-vehicle control computer 150 can control the autonomous vehicle to slow down by a predetermined amount at least a predetermined distance ahead of arriving at a detected icy roadway. Examples of the threshold depth include 0.5 inch, 0.75 inch, 1 inch, 1.25 inches, 1.5 inches; the threshold coefficient of friction can include 0.4, 0.45, 0.5, 0.55, 0.6; a predetermined amount of slowdown can be 20%, 22%, 25%, 27% of the current speed limit; and a predetermined distance can include 40 m, 45 m, 50 m, and 55 m. However, other thresholds including lower or higher thresholds can also be used depending on the implementation.

In some embodiments, the in-vehicle control computer 150 can also be configured to change lanes depending on the detected amount of snow and/or sleet accumulation. For example, on right-hand drive roadways, the in-vehicle control computer 150 can control the autonomous vehicle 105 to drive on the left side of the road (e.g., biasing to the left side of the current lane) in response to the detected amount of snow and/or sleet accumulation being less than a threshold depth. The threshold depth may be 0.5 inch, 0.75 inch, 1 inch, 1.25 inches, 1.5 inches.

The in-vehicle control computer 150 can be configured to detect environmental conditions that are indicative of black ice on the roadway. For example, the in-vehicle control computer 150 can detect the combination of the ambient temperature being less than a threshold temperature and the water level near the roadway being less than 10% of the road crown, and in response, the in-vehicle control computer 150 can control the autonomous vehicle to slow down to a predetermined speed. Depending on the embodiment, the threshold temperature may be 3° C., 4° C., 5° C., however, other threshold temperatures are also possible.

In some embodiments, the predetermined speed may be 15 mph, 20 mph, or 25 mph, however, other speeds are also possible. The in-vehicle control computer 150 can also determine whether the traction of the autonomous vehicle 105 is less than a predetermined threshold value, and in response to the traction being less than the predetermined value, the in-vehicle control computer 150 can control the autonomous vehicle 105 to execute the first MRC maneuver. The predetermined threshold value may be, for example, 0.4, 0.45, 0.5, 0.55, 0.6, while other values are also possible.

In response to detecting black ice, the in-vehicle control computer 150 may inform the oversight system 350 and provide any associated detected environmental conditions (e.g., temperature, water level, traction, etc.). The in-vehicle control computer 150 can also activate the autonomous vehicle’s 105 hazard lights in response to detecting black ice.

The in-vehicle control computer 150 can also be configured to detect ice reflection. For example, the in-vehicle control computer 150 can determine whether light reflecting from snow is hindering the visibility of one of more sensors of the vehicle sensor subsystems 144. In response to determining that the light reflected from snow is affecting visibility of one or more sensors, the vehicle sensor subsystems 144 can control the autonomous vehicle 105 to slow down by a predetermined amount of the current speed limit and prioritize information coming from the onboard localization system to continue navigation. The predetermined amount may include, for example, 20%, 22%, 25%, 27% of the current speed limit, although other predetermined amounts are also possible.

Road Traction Response

As mentioned above, the in-vehicle control computer 150 can also be configured to monitor the road traction as one of the environmental conditions detected by the in-vehicle control computer 150. As used herein, road traction generally refers to the friction between a drive wheel of the autonomous vehicle 105 and the road surface. Low road traction generally refers to a road traction with a coefficient that is less than a threshold value, for example, 0.4, 0.5, 0.6, although other coefficients are also possible.

The in-vehicle control computer 150 can be configured to detect a degraded traction level when the autonomous vehicle 105 is required to slow down to levels below normal speeds but still over 30 mph due to extended stopping distance or impaired maximum available deceleration rate. As used herein, a degraded traction level may generally refer to a degraded weather condition that causes a decrease to the autonomous vehicle’s 105 traction due to inclement weather but is still within ODD.

In some embodiments, the in-vehicle control computer 150 can be configured to detect a degraded traction condition in response to one or more of the following conditions being satisfied: the autonomous vehicle 105 modifies its behavior and speed to respond to inclement weather that contains degraded traction levels.

In one example scenario, the in-vehicle control computer 150 can be configured to detect a change in traction that dictates a degraded weather response. In response, the in-vehicle control computer 150 can cause the autonomous vehicle 105 to perform one or more of the following actions: reduce its speed to ensure a stopping distance with the maximum available deceleration rate always remains available, lane change with critical intent, apply the maximum available deceleration rate or less to decelerate, if safe to do so, lane change to the right-most lane, and maintain a preference for the right-most lane.

The in-vehicle control computer 150 can be configured to detect a cautionary traction level and slow the autonomous vehicle 105 to a speed below 30 mph due to an extended stopping distance or impaired maximum available deceleration rate. As used herein, a cautionary traction level generally refers to a cautionary weather condition that causes a decrease to the autonomous vehicle’s 105 traction due to inclement weather and is at risk of becoming out of ODD.

In one example scenario, the in-vehicle control computer 150 can be configured to detect a change in traction that dictates a cautionary weather response. In response, the in-vehicle control computer 150 can cause the autonomous vehicle 105 to perform one or more of the following actions: execute lane change maneuvers to the right-most lane for the duration of any cautionary weather, activate the autonomous vehicle’s 105 emergency lights until the cautionary weather conditions have concluded, reduce the autonomous vehicle’s 105 speed to ensure a stopping distance with maximum available deceleration rate always remains available, avoid all lane changes, except for those that are required for safety (e.g., lane change to the right-most lane) or those required to continue the autonomous vehicle’s 105 mission (e.g., to take an exit), if the autonomous vehicle 105 must lane change, the autonomous vehicle 105 shall use critical lane change, apply a maximum available deceleration rate or less to decelerate, and lane biases to avoid collision.

The in-vehicle control computer 150 can be configured to estimate the road traction between the drive wheels of the autonomous vehicle 105 and the road surface. In some embodiments, the in-vehicle control computer 150 can estimate the road traction based on one or more of the determined environmental conditions and/or the current temperature. The in-vehicle control computer 150 can be further configured to predict the road traction that the autonomous vehicle 105 will experience at a given time in the future based on the environmental conditions and/or the temperature that the autonomous vehicle 105 is expected to experience at the future time.

In some embodiments, the in-vehicle control computer 150 can be configured to determine that there is a risk of low road traction in response to the temperature being less than a threshold temperature due to an increased risk of black ice being present on the roadway below the threshold temperature. In some implementations, the threshold temperature may be 2° C., 3° C., 4° C., although other threshold values are also possible.

The in-vehicle control computer 150 can further be configured to use the road surface type as an input in estimating the road traction. The in-vehicle control computer 150 can determine the road surface type based on the predetermined map and/or a determination of the road surface type based on the data obtained from one or more sensors of the vehicle sensor subsystems 144. Example road surface types which can be defined in the map and/or determined based on sensor data include asphalt, mud, sand, gravel, wet leaves.

In some embodiments, the in-vehicle control computer 150 can also be configured to estimate the road traction based at least in part on detecting understeering of the autonomous vehicle 105. For example, the in-vehicle control computer 150 can determine that the autonomous vehicle 105 is experiencing a degraded road traction level based on a detected response of the autonomous vehicle 105 body to maximum acceleration while accelerating and maximum deceleration while slowing down.

In some implementations, the in-vehicle control computer 150 can also use a determined wheel torque in detecting the road traction level. As used herein, wheel torque generally refers to the sum of the torques applied by the autonomous vehicle’s 105 powertrain and braking actuators. The in-vehicle control computer 150 can detect the road traction level based on a detected response of the autonomous vehicle’s 105 body to the applied wheel torque. In some embodiments, the in-vehicle control computer 150 can determine the road traction level based on a slip rate from the tires of the autonomous vehicle 105. This determination can be supplemented with a detected temperature and/or climate information in some implementations.

In some embodiments, when the in-vehicle control computer 150 determines that the road traction level is less than the threshold road traction level, the in-vehicle control computer 150 can limit lateral acceleration to a threshold lateral acceleration value and limit jerk to a threshold jerk value. By limiting the lateral acceleration and jerk, the in-vehicle control computer 150 can reduce the risk of the autonomous vehicle 105 losing traction with the road surface. In some embodiments, the threshold lateral acceleration value may be 1.5 m/s2, 2 m/s², 2.5 m/s2 and the threshold jerk value may be 0.75 m/s3, 1 m/s3, 1.25 m/s3, 1.5 m/s3, 2 m/s3, however, other thresholds are also possible. The in-vehicle control computer 150 can also be configured to limit lateral acceleration for all or substantially all lateral maneuvers (e.g., lane change, lane bias, curbs) when the estimated or determined road traction level is less than the threshold value.

The in-vehicle control computer 150 can further be configured to dynamically adjust a following distance from other vehicles directly ahead of the autonomous vehicle 105 (e.g., within the current lane of the autonomous vehicle 105) based at least in part on the estimated road traction level and a safe longitudinal deceleration required to completely stop. For example, the in-vehicle control computer 150 can determine the safe longitudinal deceleration required to completely stop based on the road surface type and the estimated road traction level. The in-vehicle control computer 150 can be configured to determine the following distance to be greater than the safe longitudinal deceleration required to completely stop.

Road Water Operational Limits

Another environmental condition that the in-vehicle control computer 150 can be configured to monitor is road water, which can include fog and flooding. When road water environmental conditions are present, the in-vehicle control computer 150 can be configured to adjust one or more driving parameters of the autonomous vehicle 105 that govern the range of actions that can be autonomously executed by the autonomous vehicle 105 such that the autonomous vehicle 105 can safely navigate the detected road water conditions.

One aspect of detecting whether fog may be present can include the in-vehicle control computer 150 detecting fog road warning signs. In some embodiments, the in-vehicle control computer 150 can, based on data received from one or more sensors of the vehicle sensor subsystems 144, detect traffic signs that provide a warning of a fog area at a predetermined minimum distance ahead of the autonomous vehicle 105. The predetermined minimum distance may be, for example, 200 m, 222 m, 250 m, 300 m, however, other distances are also possible. FIG. 6H illustrates an example visualization of a traffic sign that may identify a fog area in accordance with aspects of this disclosure.

As discussed herein, the in-vehicle control computer 150 may store a map within the memory 175 that includes a map of the roadways and nearby environment (see the Map Taxonomy section of this application). The map can include the locations of fog areas and/or roadway areas which have at least a predetermined probability of becoming foggy. For example, the locations indicative of fog areas can include any roadways for which fog warning signage is present as well as any roadways which have been detected by an autonomous vehicle 105 in the fleet as having experienced fog in the past.

In response to determining that the autonomous vehicle 105 is in a fog area, the in-vehicle control computer 150 can be configured to estimate the visibility range for one or more of the sensors of the vehicle sensor subsystems 144 based on the detected visibility of the sensors of the vehicle sensor subsystems 144. In addition, the in-vehicle control computer 150 can be configured to adjust one or more driving parameters of the autonomous vehicle 105 in response to determining that the autonomous vehicle 105 is in a fog area and/or has reduced visibility. For example, when the estimated visibility range is less than a threshold distance, the in-vehicle control computer 150 can control the autonomous vehicle 105 to slow down by a predetermined amount at least a predetermined minimum distance before entering a fog area. In some embodiments, the threshold distance can be, for example, 45 m, 53.3 m, 60 m, the predetermined amount can be, for example, 20%, 25%, 30% of the current speed limit, and the predetermined minimum distance can be, for example, 40 m, 45 m, 50 m, 55 m, although other values are also possible. The in-vehicle control computer 150 can also be configured to activate the autonomous vehicle’s 105 low beams prior to entering the fog area, for example, at or before the predetermined minimum distance before entering the fog area.

In some implementations, the in-vehicle control computer 150 can further be configured to detect flooded areas, for example, by detecting the presence of flooded road signs. The in-vehicle control computer 150 may also be configured to inform the oversight system 350 in response to detecting the flooded road signs such that the oversight system 350 can update the map and provide an indication of the flooded area to other vehicles in the fleet.

As discussed herein, the in-vehicle control computer 150 can be configured to compare data received from the one or more sensors of the vehicle sensor subsystems 144 to data stored in the map to provide a level of redundancy. For example, when the data received from the one or more sensors of the vehicle sensor subsystems 144 matched the mapped data of the environment, the in-vehicle control computer 150 can have a higher level of confidence that both sets of data correctly reflect the state of the environment.

In the context of flood roadways, when there is a discrepancy between the mapped flooded areas and the flooded areas determined based on data obtained via the one or more sensors of the vehicle sensor subsystems 144, the in-vehicle control computer 150 can inform the oversight system 350 of the discrepancy and the location of the discrepancy and the autonomous vehicle 105.

In certain implementations, the in-vehicle control computer 150 can also be configured to estimate the level of the water in a flooded area, for example, based on the road crown visibility. In response to the water level being greater than a predetermined amount, the in-vehicle control computer 150 can be configured to inform the oversight system 350. The predetermined amount can be, for example, 18%, 20%, 22%, 25% of the road crown, however, other amounts are also possible.

The map can also include the locations of flooded areas. For example, the locations indicative of flooded areas can include any roadways for which flood warning signage is present as well as any roadways which have been detected by an autonomous vehicle 105 in the fleet as experiencing flooding.

The in-vehicle control computer 150 can also be configured to take action in response to detecting the presence of a flooded area. For example, the in-vehicle control computer 150 can be configured to slow the autonomous vehicle 105 down by a predetermined amount of the current speed limit at least a predetermined distance before entering the flooded areas in response to determining that the level of water is less than a predetermined threshold amount of the road crown and the coefficient of friction between the road and the autonomous vehicle 105 is greater than a threshold coefficient of friction value. In some embodiments, the predetermined amount that the autonomous vehicle 105 is slowed can be, for example, 20%, 22%, 25%, 28%, 30% of the current speed limit, the predetermined distance before entering the flooded areas can be, for example, 40 m, 45 m, 50 m, 55 m, the predetermined threshold amount of the road crown can be, for example, 18%, 20%, 22%, and the threshold coefficient of friction value can be, for example, 0.4, 0.5, 0.6. However, other threshold values can be used without departing from aspects of this disclosure.

In some embodiments, rather than slowing down when approaching a flooded area, the in-vehicle control computer 150 can be configured to take an alternate route. For example, when the in-vehicle control computer 150 determines that the level of water is greater than a predetermined amount of the road crown, the in-vehicle control computer 150 can find an alternate route to continue the autonomous vehicle’s 105 travel to the destination. In some embodiments, the predetermined amount of the road crown can be, for example, (e.g., 18%, 20%, 22%, 25%), although other values are also possible.

The in-vehicle control computer 150 can further be configured to use alternative sources of localization when one or more traffic lane markings are covered with water. For example, when a traffic lane marking used in part for localization of the autonomous vehicle 105 is covered in water, the in-vehicle control computer 150 can be configured to use the onboard localization system to ensure that the autonomous vehicle 105 is moving in the right direction.

The in-vehicle control computer 150 can also be configured to detect and respond to flooded and partially flooded roadways. As used herein, a partially flooded roadway generally refers to a roadway that has detected road water that is still within the autonomous vehicle’s 105 ODD. A flooded roadway generally refers to when the road water levels are considered out of the autonomous vehicle’s 105 ODD.

The in-vehicle control computer 150 can be configured to classify a partially flooded area as degraded weather condition or cautionary weather condition in response to detecting a partially flooded roadway. The in-vehicle control computer 150 can be configured to classify a flooded roadway as a critical weather condition in response to detecting a flooded roadway.

In one example scenario, the in-vehicle control computer 150 can be configured to detect a partially flooded roadway and classify the partially flooded roadway as degraded weather condition. In response, the in-vehicle control computer 150 can perform one or more of the following actions: reduce the autonomous vehicle’s 105 speed to ensure a stopping distance with the maximum available deceleration rate always remains available, lane change with critical intent and lane bias to avoid collision, apply the maximum available deceleration rate or less to decelerate, and if safe to do so, lane change to the right-most lane.

In another example scenario, the in-vehicle control computer 150 can be configured to detect a partially flooded roadway and classify the partially flooded roadway as a cautionary weather condition. In response, the in-vehicle control computer 150 can perform one or more of the following actions: execute lane change maneuvers to the right-most lane for the duration of the cautionary weather condition, activate the autonomous vehicle’s 105 emergency lights until the cautionary weather conditions have concluded, reduce the speed of the autonomous vehicle 105 to ensure a stopping distance with the maximum available deceleration rate always remains available, apply the maximum available deceleration rate or less to decelerate, and lane bias to avoid collision.

In yet another example scenario, the in-vehicle control computer 150 can be configured to detect a flooded roadway and classify the flooded roadway as a critical weather condition. In response, the in-vehicle control computer 150 can attempt to find an alternative route, and if an alternative route to avoid flooded roadway is not found, perform one or more of the following actions: activate the autonomous vehicle’s 105 emergency lights, determine a proper MRC maneuver to conduct, execute the MRC maneuver, contact the oversight system 350, and enter a safe state to protect the autonomous vehicle 105 during the extreme weather event and keep the hazard lights on for visibility.

In still yet another example scenario, the in-vehicle control computer 150 can be configured to detect a flooded roadway ahead and classify the flooded roadway as a critical weather condition. In response, the in-vehicle control computer 150 can attempt to find an alternative route, and in response to finding an alternative route to avoid the flooded roadway: verify that the alternative route does not intersect with the flooded roadway and take the alternative route to continue the mission.

Headlight Usage

Another aspect related to the detection of environmental conditions is the automated actuation of the autonomous vehicle’s 105 headlights. The autonomous vehicle 105 can be equipped with at least low-beams and high-beams. In some implementations, the low-beams can provide coverage of about 60.96 m (200 ft) while the high-beams can provide coverage of about 106.68-133.33 m (350-400 ft).

The in-vehicle control computer 150 can be configured to track the areas of the environment that are illuminated by the headlights based on a defined lighting zone. In some implementations, the in-vehicle control computer 150 can define the lighting zone as an area in the road illuminated by the autonomous vehicle’s 105 high-beams. The headlight beam can be defined to be enclosed horizontally by a horizontal spread angle (α), where external boundaries are considered; bounded vertically by an upward vertical spread angle (β); and the distance ahead circumscribed to the headlight range (Rg). FIGS. 6I-6K illustrate example visualizations of lighting zones in accordance with aspects of this disclosure.

The in-vehicle control computer 150 can be configured to turn on the autonomous vehicle’s 105 headlights in low visibility conditions, (e.g., fog, sun glare, rain, dust, etc.), to make the autonomous vehicle 105 visible to others. The in-vehicle control computer 150 can also turns on the low-beam headlights during inclement weather so other road users detect the autonomous vehicle 105, thereby improving roadway safety. The in-vehicle control computer 150 can further engage the low-beam headlights during inclement weather.

When in a cautionary or critical weather condition, the in-vehicle control computer 150 can activate the hazard lights to alert other road users of cautionary driving behavior. Hazard light usage laws vary from state to state, for example, in Texas this use of hazard lights is ok. The in-vehicle control computer 150 can use hazard lights while in cautionary or critical weather conditions.

Degraded environmental conditions such as snow, rain, fog, sleet, and/or smoke can reduce visibility, making it difficult for the sensors to see objects in the environment and for the autonomous vehicle 105 to be seen. Though these conditions may depend on state or other local laws, in some embodiments, degraded visibility may be defined as visibility that is less than a predetermined threshold distance (e.g., 800 feet, 900 feet, 1000 feet, 1100 feet) in most states in the US.

As used herein, a degraded visibility level may generally refer to the distance calculated by the formula: [(Speed Limit (m/s)) * (8 seconds)] to [(Speed Limit (m/s)) * (8 seconds) * (¾)]. However, other calculations are also possible to determine degraded visibility. Degraded visibility can also generally refer to a degraded weather condition that causes impairment to the autonomous vehicle’s 105 visibility range due to inclement weather but is still within ODD.

In some embodiments, the in-vehicle control computer 150 can detect a visibility condition when the following condition being met: the autonomous vehicle modifies its behavior and speed to respond to inclement weather that contains degraded visibility levels.

In one example scenario, the in-vehicle control computer 150 can be configured to detect a change in visibility that dictates a degraded weather response. In response, the in-vehicle control computer 150 can perform one or more of the following actions: reduce the speed of the autonomous vehicle 105 to ensure a stopping distance with the maximum available deceleration rate always remains available, lane change with critical intent if target back critical distance behavior can be confirmed, if safe to do so, lane change to the right-most lane, and maintains a preference for the right-most lane.

As used herein, a cautionary visibility level can generally refer to a distance calculated by the formula: [(Speed Limit (m/s)) * (8 seconds) * (¾)] to [(Speed Limit (m/s)) * (8 seconds) * (⅔)]. However, other calculations are also possible to determine degraded visibility. Cautionary visibility level can also refer to a cautionary weather condition that causes impairment to the autonomous vehicle’s 105 visibility range due to inclement weather and is at risk of becoming out of ODD.

In some embodiments, the in-vehicle control computer 150 can be configured to detect a cautionary visibility condition when the following condition are met: the autonomous vehicle 105 modifies its behavior and speed to respond to inclement weather that contains cautionary visibility levels.

In one example scenario, the in-vehicle control computer 150 can be configured to detect a change in visibility that dictates a cautionary weather response. In response, the in-vehicle control computer 150 can perform one or more of the following actions: execute lane change maneuvers to the right-most lane for the duration of any cautionary weather, activates the autonomous vehicle’s 105 emergency lights until the cautionary weather conditions have concluded, reduces speed to ensure a stopping distance with the maximum available deceleration rate always remains available, avoids all lane changes, except for those that are required for safety (e.g., lane change to the right-most lane) or those required to continue the autonomous vehicle’s 105 mission (e.g., to take an exit), and if the autonomous vehicle 105 must lane change, the autonomous vehicle 105 should use critical lane change.

The in-vehicle control computer 150 can determine that the visibility is a degraded environmental condition when the visibility of one or more of the sensors in the vehicle sensor subsystems 144 is less than a predetermined threshold distance. The predetermined distance threshold may be, for example, 800 feet, 900 feet, 1000 feet, 1100 feet. The in-vehicle control computer 150 can use second and third predetermined distance threshold to identify the visibility as a cautionary or critical environmental condition.

The in-vehicle control computer 150 can also detect the presence of traffic signs that can indicate that the use of headlights would be appropriate. In some embodiments, the in-vehicle control computer 150 can activate the headlights at least in part based on the detection of such traffic signage. FIGS. 6L-6O illustrate example visualizations of a traffic signs that may identify that the use of headlights is appropriate in accordance with aspects of this disclosure.

In determining whether to activate the headlight, the in-vehicle control computer 150 can perceive degraded environmental conditions (also referred to as adverse or bad weather conditions) such as blizzard, high wind, snow, rain, and/or sleet.

In some embodiments, the in-vehicle control computer 150 can be configured to detect the presence of other entities (e.g., vehicles, pedestrians, etc.) within the lighting zone of the headlights.

In some embodiments, the in-vehicle control computer 150 can be configured to turn on low-beams in response to determining that the autonomous vehicle 105 is inside a tunnel.

The in-vehicle control computer 150 can further be configured to turn on the low-beams at night or at any time defined by local (e.g., state) law. For example, when the autonomous vehicle 105 is in Pennsylvania, the in-vehicle control computer 150 can be configured to turn on low-beams from sunset to sunrise.

The in-vehicle control computer 150 can be configured to turn on low-beams in response to detecting degraded or more severe environmental conditions. For example, the in-vehicle control computer 150 can be configured to turn on low-beams in response to detecting certain types of inclement weather, such as: snow, rain, fog, sleet, and/or smoke which can reduce visibility.

In some implementations, the in-vehicle control computer 150 can be configured to turn on low-beams in response to the autonomous vehicle’s 105 wipers being in continuous use for longer than a predetermined length of time. The predetermined length of time may be, for example, 10 s, although other lengths of time are also possible. The in-vehicle control computer 150 can be configured to turn on low-beams in response to the wipers being in continuous use for longer than the predetermined length of time when required for compliance with local laws, such as in Pennsylvania, Alabama, and California.

The in-vehicle control computer 150 can also be configured to turn on low-beams when visibility is less than a minimum threshold value as required by local (e.g., state) law. For example, in Pennsylvania, the minimum threshold value may be about 304.8 m (1000 feet).

The in-vehicle control computer 150 can further be configured to turn on low-beams in a number of other scenarios, such as in a construction zone, when the road grade is greater than a predetermined threshold level, and/or when mandated by a detected traffic sign. This use of low beams can increase the visibility of the autonomous vehicle 105 when doing so can increase safety by making the autonomous vehicle 105 more visible to other entities on the road. The predetermined threshold level may be, for example, a road grade of 2%, 3%, 4%, although other levels are also possible. FIGS. 6P-6R illustrate example visualizations of a traffic signs that may identify that the use of headlights is required in accordance with aspects of this disclosure.

In some embodiments, the in-vehicle control computer 150 can further be configured to turn off high-beams in response to detecting an entity in or about to enter the lighting zone of the autonomous vehicle’s 105 low-beam headlights. The in-vehicle control computer 150 can also be configured to turn on the high-beams at night in response to detecting the absence of other entities in the autonomous vehicle’s 105 lighting zone. FIG. 6S illustrates and example visualization of one or more entities which are within the autonomous vehicle’s 105 lighting zone in accordance with aspects of this disclosure.

Example Technique for Controlling an Autonomous Vehicle Based on Environmental Conditions

One objective of this disclosure includes controlling an autonomous vehicle 105 based at least in part on the current environmental conditions in which the autonomous vehicle 105 is experiencing. FIG. 6T illustrates an example method which can be used to control the autonomous vehicle 105 taking into account environmental conditions detected by at least one perception sensor. The method 600 may be described herein as being performed by one or more processors, which may include the in-vehicle control computer 150.

The method 600 begins at block 601. At block 602, the in-vehicle control computer 150 is configured to receive perception data from at least one perception sensor of an autonomous vehicle.

At block 604, the in-vehicle control computer 150 is configured to receive an indication of current weather conditions from an external weather condition source. For example, the external weather condition source can include the United States Weather Service.

At block 606, the in-vehicle control computer 150 is configured to determine a current environmental condition severity level from a plurality of severity levels based on the perception data and the indication of current weather conditions.

At block 608, the in-vehicle control computer 150 is configured to modify one or more driving parameters that govern a range of actions that can be autonomously executed by the autonomous vehicle. The driving parameters may include instructions for controlling movement of the autonomous vehicle 105 based on one or more of: environmental conditions, other vehicles and/or object on the roadways, the localization of the autonomous vehicle 105, the current route of the autonomous vehicle 105, etc.

At block 610, the in-vehicle control computer 150 is configured to navigate the autonomous vehicle based on the modified one or more driving parameters. The method 600 ends at block 610.

General Driving Behavior

The autonomous vehicle 105 can be configured to perform a number of different tasks while navigating under normal or general driving conditions. For example, the autonomous vehicle 105 can be configured to, under normal or optimal conditions, operate according to a default decision framework that includes certain behavior associated with the autonomous vehicle’s 105 trailer load, recognizing and responding to traffic signs, and maintaining proper positioning within the autonomous vehicle’s 105 lane.

In certain embodiments, the autonomous vehicle 105 can include an in-vehicle control computer 150 configured to estimate a grade of the roadway based on perception data indicative of one or more parameters of the roadway received from one or more perception sensors of an autonomous vehicle, provide a first control input to the autonomous vehicle based on the grade of the roadway, determine a response of the autonomous vehicle to the first control input based on perception data indicative of movement of the autonomous vehicle received from the one or more perception sensors, estimate a trailer load of the trailer based on the response of the autonomous vehicle to the first control input, and provide a second control input to the autonomous vehicle based on the grade of the roadway and the trailer load. Accordingly, the in-vehicle control computer 150 can adjust controls provided to the autonomous vehicle 105 in order to respond to a determined road grade and trailer load without needing to have the road grade and trailer load manually input into the autonomous vehicle 105.

Trailer Load Behavior

One important aspect involved in safely navigating an autonomous vehicle 105 is the detection of and response to various conditions that can affect the autonomous vehicle’s 105 behavior when operating with a loaded trailer.

In some embodiments, the in-vehicle control computer 150 can be configured to detect or estimate the road grade in front of the autonomous vehicle 105. The in-vehicle control computer 150 can also be configured to dynamically adjust throttle (e.g., acceleration) and brake (e.g., deceleration) control based at least in part on the detected road grade.

The in-vehicle control computer 150 can also be configured to receive the information about the type of load and cargo in the yard. For example, the in-vehicle control computer 150 can receive the load/cargo configuration of one or more of the following: the trailer type, the cargo type, and/or the type of load. Example trailer types include: dry van, flatbed, and refrigerated. Further example trailer types include: 53′ dry van trailer with standard dimensions, 53′ refrigerated trailers with standard dimensions, 48′ dry van trailer with standard dimensions, and 48′ refrigerated trailers with standard dimensions. Example cargo types include: large equipment, consumer goods, raw materials, etc. Example load types include: fully loaded, partially loaded, empty, etc.

In some embodiments, the in-vehicle control computer 150 can be configured to estimate trailer load from the autonomous vehicle’s 105 acceleration response based on throttle and/or braking inputs. The in-vehicle control computer 150 can also consider the relationship between the requested wheel torque and the autonomous vehicle’s 105 acceleration to estimate the mass of the trailer. The in-vehicle control computer 150 can further be configured to estimate the force that can be used to move the trailer to adjust the throttle dynamically and brake control to compensate for trailer load based on the wheel torque.

The in-vehicle control computer 150 can also be configured to detect the road curvature in front of the autonomous vehicle 105 with a distance greater than a stopping distance to limit lateral acceleration and maintain stability in curves. That is, the in-vehicle control computer 150 can be configured to adjust lateral acceleration and maintain stability in curves using the detected road curvature. Depending on the embodiment, the in-vehicle control computer 150 can cause the autonomous vehicle 105 to decelerate at rates when stopping the autonomous vehicle 105. The in-vehicle control computer 150 can also be configured to limit lateral acceleration in the curves based on a distance that can reduce the vehicle speed to limit lateral acceleration in the curves taking into account the braking capabilities of the autonomous vehicle 105. The in-vehicle control computer 150 can also be configured to reduce the autonomous vehicle’s 105 speed to limit lateral acceleration based on the roadway’s detected maximum curvature.

In some embodiments, the in-vehicle control computer 150 can be configured to dynamically adjust the throttle control to compensate for the determined trailer load and the road grade in order to provide a longitudinal control robustness for the throttle control. The in-vehicle control computer 150 can also be configured to dynamically adjust the brake control to compensate for the determined trailer load and the road grade in order to provide a longitudinal control robustness for the brake control. The in-vehicle control computer 150 can further be configured to dynamically adjust the steering control to compensate for side wind effects and a super elevation rate due to trailer load in order to provide a lateral control robustness of the steering control. As used herein, the super elevation rate may generally refer to a ratio of the roadway slope to width. The in-vehicle control computer 150 can be configured to control the lateral position of the autonomous vehicle 105 to compensate for lateral resistive forces. FIG. 7A illustrates an example visualization of the forces (e.g., lateral resistive forces) which may be relevant to an autonomous vehicle 105 driving on a roadway with an incline. For example, the autonomous vehicle 105 may experience a lateral resistive force 720 and a force due to gravity 722.

In some embodiments, the in-vehicle control computer 150 can be configured to limit lateral acceleration to a predetermined acceleration and a predetermined jerk value to maintain the stability of the truck (e.g., not flip over) when turning or driving on curved roads taking into account the super elevation rate. The predetermined acceleration can include, for example, 1 m/s2, 2 m/s², although other values are also possible without departing from aspects of this disclosure. The in-vehicle control computer 150 can also be configured to limit lateral dynamics for some or all lateral maneuvers (lane change, lane bias, curbs) of the autonomous vehicle 105 depending on trailer inertia and stability criteria. The in-vehicle control computer 150 can be configured to reduce speed of the autonomous vehicle 105 to maintain a lateral acceleration. The in-vehicle control computer 150 can also be configured to limit the steering wheel angle velocity to limit the lateral jerk.

In some embodiments, the in-vehicle control computer 150 can be configured to decelerate the autonomous vehicle 105 with a maximum deceleration of up to 5 m/s² and a maximum jerk value up to 2 m/s3, depending on the determine type of load. However, the maximum deceleration and maximum jerk can vary depending on the particular embodiment.

The in-vehicle control computer 150 can also be configured to accelerate the autonomous vehicle 105 with a maximum acceleration depending on the determined load and a maximum jerk depending on the determined type of load. The maximum acceleration can range from 1 m/s² to 3 m/s2 and the maximum jerk can range from 1 m/s3 to 2 m/s3, however, other ranges are also possible.

In some embodiments, the in-vehicle control computer 150 can be configured to increase and anticipate a following distance to a vehicle ahead of the autonomous vehicle 105 to account for the allowed longitudinal acceleration and jerk due to the determined trailer load, road grade, and traction. In adjusting the following distance, the in-vehicle control computer 150 can also be configured to consider braking capabilities such as the maximal longitudinal acceleration achievable depending on one or more of the following: the type of trailer, load, cargo, road grade, and/or traction.

Traffic Signs

Another important aspect involved in safely navigating an autonomous vehicle 105 is the detection of traffic signs as well as properly taking action based on the detection of traffic signs. Thus, the in-vehicle control computer 150 can be configured to detect the presence and type of traffic signs based on perception data generated by one or more sensors of the vehicle sensor subsystems 144. It is desirable for the autonomous vehicle 105 to also detect the information communicated by the traffic signs so that the autonomous vehicle 105 can follow any directions indicated by the traffic signs. The in-vehicle control computer 150 can also be configured to compare the information detected on a traffic sign with corresponding traffic sign information included in the map of the roadways and nearby environment (see the Map Taxonomy section of this application). By comparing the detected traffic sign information with the traffic sign information from the map, the in-vehicle control computer 150 can provide a level of redundancy and higher confidence in the detected traffic sign information.

In some embodiments, the in-vehicle control computer 150 can be configured to detect all traffic signs at a predetermined minimum distance away from the autonomous vehicle 105 measured from the frontmost point of the autonomous vehicle 105, unless the traffic sign is obstructed from view. The predetermined minimum distance away from the autonomous vehicle 105 can include, for example, 200 m, 300 m, 400 m, although other distances are also possible without departing from aspects of this disclosure.

The in-vehicle control computer 150 can be configured to update the map with the identifications and locations of all traffic signs. For example, if the in-vehicle control computer 150 determines that a detected traffic sign is missing from the map, the in-vehicle control computer 150 can be configured to update the map to include the newly detected traffic sign.

The in-vehicle control computer 150 can be configured to take specific actions depending on the type of traffic sign that has been detected. For example, the in-vehicle control computer 150 can be configured to take actions in response to detecting each of the following traffic sign types: stop signs, yield signs, no turn signs, no right turn signs, right turn only signs, no left turn signs, no trucks signs, pedestrian crossing signs, truck route signs, weight limit signs, road closure signs, mandatory freeway exit signs, environment precaution signs, reduced speed limit ahead signs, merging signs, non-vehicular signs, and advanced turn signs.

The in-vehicle control computer 150 can be configured to control the autonomous vehicle 105 to take particular actions in response to detecting a stop sign.

In response to detecting a yield sign, the in-vehicle control computer 150 can be configured to slow the autonomous vehicle 105 down, to a complete stop, if necessary, in order to let other vehicles with the right-of-way pass before proceeding. FIGS. 7B-7C illustrate example visualizations of yield signs.

In response to detecting a no turn sign, the in-vehicle control computer 150 can be configured to only initiate turns on roads that do not have a no-turns sign. FIGS. 7D-7E illustrate example visualizations of no-turn signs.

In response to detecting a no-right-turn sign, the in-vehicle control computer 150 can be configured to only initiate right turns when the autonomous vehicle 105 is not on a designated no-right-turn road. FIG. 7F illustrates an example visualization of a no-right-turn sign.

In response to detecting a right-turn-only sign, the in-vehicle control computer 150 can be configured to control the autonomous vehicle 105 to perform a right turn if it is in a designated right-turn-only lane. If a right turn is not intended and the autonomous vehicle 105 has not passed the solid white line represented by a right-turn-only lane, then the in-vehicle control computer 150 can be configured to control the autonomous vehicle 105 to initiate a lane change. In some cases, right-turn-only lanes can be initiated by a dotted white line becoming a solid white line and contains one of the signs in FIGS. 7G-7I. FIGS. 7G-7I illustrate example visualizations of signs which include right-turn-only lanes.

In response to detecting a no-left-turn sign, the in-vehicle control computer 150 can be configured to control the autonomous vehicle 105 to only perform left hand turns when the autonomous vehicle 105 is not at a designated no-left-turn intersection. FIGS. 7J-K illustrate example visualizations of no-left-turn signs.

In response to detecting a left turn only sign, the in-vehicle control computer 150 can be configured to control the autonomous vehicle 105 to perform a left turn if the autonomous vehicle 105 is in a designated left-turn-only lane. If a left turn is not intended and the autonomous vehicle 105 has not passed the solid white line represented by a left-turn-only lane, then the in-vehicle control computer 150 can be configured to control the autonomous vehicle 105 to initiate a lane change. Left-turn-only lanes can be initiated by a dotted white line becoming a solid white line and contains one of the signs indicated in FIGS. 7L-7M. FIGS. 7L-7M illustrate example visualizations of signs which include left-turn-only lanes.

In response to detecting a no-trucks sign, the in-vehicle control computer 150 can be configured to control the autonomous vehicle 105 to exit the road and reroute. FIG. 7N illustrates an example visualization of a no-trucks sign.

The in-vehicle control computer 150 can be configured to control the autonomous vehicle 105 to take particular actions in response to detecting a pedestrian crossing sign. FIGS. 7O-V illustrate example visualizations of pedestrian-crossing signs.

In response to detecting a truck-route sign, the in-vehicle control computer 150 can be configured to control the autonomous vehicle 105 to abide by a truck-route lane instruction. FIG. 7W illustrates an example visualization of a truck-route sign.

In response to detecting a weight-limit sign, the in-vehicle control computer 150 can be configured to, in response to determining that the autonomous vehicle 105 does not meet the weight requirement at a designated weight station, control the autonomous vehicle 106 to exit the road and reroute. FIG. 7X-7AC illustrate example visualizations of weight-limit signs.

In response to detecting a road-closure sign, the in-vehicle control computer 150 can be configured to control the autonomous vehicle 105 to exit the road and reroute. FIG. 7AD-7AF illustrate example visualizations of road-closure signs.

In response to detecting a mandatory-freeway-exit sign, the in-vehicle control computer 150 can be configured to control the autonomous vehicle 105 to exit the road and reroute. FIG. 7AG-7AK illustrate example visualizations of mandatory-freeway-exit signs.

In response to detecting an environment-precaution sign, the in-vehicle control computer 150 can be configured to control the autonomous vehicle 105 to decelerate, such that the autonomous vehicle’s speed ranges, for example, from 25-55 MPH, until the environmental conditions are cleared. FIG. 7AL-7AZ illustrate example visualizations of environment-precaution signs.

In response to detecting a reduced-speed-limit ahead sign, the in-vehicle control computer 150 can be configured to control the autonomous vehicle 105 to proceed to decelerate safely between 1-2 m/s2 until the new speed limit is reached. FIG. 7BA-7BB illustrate example visualizations of reduced-speed-limit ahead signs.

In response to detecting a merging sign, the in-vehicle control computer 150 can be configured to control the autonomous vehicle 105 to accept merge-ins from other vehicles. FIG. 7BC-7BJ illustrate example visualizations of merging signs.

In response to detecting a non-vehicular warning sign, the in-vehicle control computer 150 can be configured to control the autonomous vehicle 105 to decelerate, to a speed ranging from 25 MPH to 55 MPH, until the area is cleared. FIG. 7BK-7BT illustrate example visualizations of non-vehicular warning signs.

In response to detecting an advanced-turn sign, the in-vehicle control computer 150 can be configured to control the autonomous vehicle 105 to decelerate until the advanced turn is completed. FIG. 7BU-BX illustrate example visualizations of advanced-turn signs.

Lane Keeping

Another important aspect involved in safely navigating an autonomous vehicle 105 is the maintaining the autonomous vehicle 105 within its lane when not performing any lane changes. For example, the in-vehicle control computer 150 can be configured to ensure that the outermost-points of the autonomous vehicle 105 (e.g., including a tractor and trailer when the autonomous vehicle 105 is embodied as a truck), including any portion of the trailer, remain within the inside edges of the lane boundaries at all times, unless changing lanes, doing a critical safety bias, evading, turning at an intersection, and/or the autonomous vehicle 105 is unable to remain within the lane boundaries due to a combination of a width of the lane and a road curvature.

While keeping the autonomous vehicle 105 within its lane, the in-vehicle control computer 150 can be configured to target a lateral position in the lane such that the widest points of the autonomous vehicle 105 are equidistant from the lane boundaries when driving straight, turning, or changing lanes, unless for an evasive maneuver, bias, or to minimize off-tracking. Advantageously, targeting an equidistant position can help increase or maximize the buffer between the autonomous vehicle 105 and the lane boundaries.

The in-vehicle control computer 150 can also be configured to monitor any deviations by the autonomous vehicle 105 from the targeted lateral position. In response to determining that the autonomous vehicle 105 has deviated from the targeted lateral position by more than a predetermined deviation distance, the in-vehicle control computer 150 can be configured to return to the targeted lateral position within a predetermined deviation time. The predetermined deviation distance can include, for example, 10 cm, 15 cm, 20 cm and the predetermined nominal deviation time can include, for example, 2 seconds, 3 seconds, 4 seconds, although other values are also possible.

While the in-vehicle control computer 150 is lane keeping the autonomous vehicle 105, the in-vehicle control computer 150 can be configured to maintain the magnitude of the autonomous vehicle’s 105 lateral acceleration to be less than a predetermined nominal value. The predetermined nominal value can include, for example, 0.5 m/s2, 0.78 m/s2, 1.0 m/s2, although other values are also possible without departing from this disclosure.

While the in-vehicle control computer 150 is lane keeping the autonomous vehicle 105, the in-vehicle control computer 150 can be configured to maintain the magnitude of the autonomous vehicle’s 105 lateral jerk to be less than a predetermined nominal value. The predetermined nominal value can include, for example, 1.5 m/s3, 1.67 m/s3, 1.8 m/s3, although other values are also possible.

The in-vehicle control computer 150 can be configured to determine the lateral distance of the autonomous vehicle 105 from marked or estimated lane boundaries with an accuracy of at least a predetermined nominal distance. The predetermined nominal distance can include, for example, 10 cm, 15 cm, 20 cm, 25 cm, although other values are also possible.

If lane markings are not present for either lane boundary, the in-vehicle control computer 150 can estimate the position of the lane boundary markings using the information from the last known lane boundary markings, any visible upcoming lane boundary markings, and/or the paths of nearby vehicles, if present.

Example Technique for Controlling an Autonomous Vehicle Based on an Estimated Trailer Load

One objective of this disclosure includes controlling an autonomous vehicle 105 based on estimating a trailer load of the autonomous vehicle 105. FIG. 7BY illustrates an example method which can be used to control the autonomous vehicle 105 based on the estimation of the trailer load. The method 700 may be described herein as being performed by one or more processors, which may include the in-vehicle control computer 150.

The method 700 begins at block 701. At block 702, the in-vehicle control computer 150 is configured to estimate a grade of the roadway based on perception data indicative of one or more parameters of the roadway received from one or more perception sensors of an autonomous vehicle.

At block 704, the in-vehicle control computer 150 is configured to provide a first control input to the autonomous vehicle based on the grade of the roadway. The control input can include steering, throttle, and/or brake controls for controlling the autonomous vehicle 105.

At block 706, the in-vehicle control computer 150 is configured to determine a response of the autonomous vehicle to the first control input based on perception data indicative of the movement of the autonomous vehicle received from the one or more perception sensors. For example, the perception data can include a wheel torque or acceleration of the autonomous vehicle 105.

At block 708, the in-vehicle control computer 150 is configured to estimate a trailer load of the trailer based on the response of the autonomous vehicle to the first control input. At block 710, the in-vehicle control computer 150 is configured to provide a second control input to the autonomous vehicle based on the grade of the roadway and the trailer load. The method 700 ends at block 712.

Object Detection and Response

As part of the navigation and control of the autonomous vehicle 105, the autonomous vehicle 105 can be configured to detect and respond to various objects present on or near the roadway. Example objects which can be relevant to the navigation of the autonomous vehicle 105 include school buses and animals. Depending on the status of a detected object, the autonomous vehicle 105 can be configured to take different actions in order to ensure the safety of all road users.

School Buses

One important aspect involved in safely navigating an autonomous vehicle 105 is the detection of and response to school buses. As used herein, a school bus may generally refer to a vehicle used for the transportation of any school pupil at or below the 12th-grade level to or from a school or school-related activity. In some embodiments, the in-vehicle control computer 150 can be configured to detect that a vehicle is a school bus in response to determining that the vehicle’s color is yellow (national school bus glossy yellow), the words “school bus” appear on the front and end of the vehicle, and/or flashing amber lights are located on the front and rear of the vehicle.

There may be at least four main identifications that are standard nationally for school buses. The first identification is that school buses may have the text “School Bus” printed in letters in black color not less than eight inches high, located between the warning signal lamps as high as possible without impairing visibility of the lettering from both front and rear, and/or have no other lettering on the front or rear of the vehicle. The second identification is that school buses may have 8 warning signal lamps located on each side of both the front and rear of the school bus, located as high as possible. The third identification is that school buses may be painted in National School Bus Glossy Yellow, in accordance with the colorimetric specification of National Institute of Standards and Technology (NIST) Federal Standard No. 595a, Color 13432, except that the hood may be either that color or lusterless black, matching NIST Federal Standard No. 595a, Color 37038. The fourth identification is that school buses may have bumpers of glossy black, matching NIST Federal Standard No. 595a, Color 17038, unless, for increased visibility, they are covered with a reflective material.

There are several types of school buses that are different by size and capacity (i.e., number of passengers). School buses can vary from a big van to a big bus that can fit up to 90 passengers. All school buses may follow the requirements mentioned above.

The in-vehicle control computer 150 can be configured to detect a school bus and its associated lane from a predetermined minimum distance. The predetermined minimum distance can include, for example, 200 m away, 250 m away, 300 m away, although other values are also possible without departing from this disclosure.

The in-vehicle control computer 150 can also be configured to detect the text “School Bus” printed in black letters on both the rear and front of the school bus from a predetermined minimum distance. The predetermined minimum distance can include, for example, 100 m away, 150 m away, 200 m away, although other distances are also possible. The in-vehicle control computer 150 can be configured to detect the text “School Bus” printed in black letters on the rear side of the school bus when following or approaching the school bus in the same direction. The in-vehicle control computer 150 can further be configured to detect the text “School Bus” printed in black letters on the front side of the school bus when approaching the school bus from the opposite direction.

In general, school buses may have the text “School Bus” printed in black letters not less than eight inches high, located between the warning signal lamps as high as possible without impairing visibility of the lettering from both front and rear, and have no other lettering on the front or rear of the vehicle.

The in-vehicle control computer 150 can be configured to detect flashing amber lights located on both the rear and front of the school bus from a predetermined minimum distance. The predetermined distance can include, for example, 200 m, 250 m, 300 m, although other distances are also possible without departing from this disclosure. The in-vehicle control computer 150 can also be configured to detect the flashing amber lights on the rear side of the school bus when following or approaching it in the same direction. The in-vehicle control computer 150 can further be configured to detect the flashing amber lights on the front side of the school bus when approaching it from the opposite direction. The in-vehicle control computer 150 can be configured to detect the flashing lights when the flashing lights are either red or yellow.

In some embodiments, the in-vehicle control computer 150 can be configured to detect the extended stop sign arm of a school bus from a predetermined minimum distance. The predetermined distance can include, for example, 200 m, 250 m, 300 m, although other values are also possible. The in-vehicle control computer 150 can be configured to detect the extended stop sign arm in response to determining that the stop sign arm is located on the driver side of the school bus. The in-vehicle control computer 150 can be also configured to detect the extended stop sign arm of the school bus in response to detecting that the extended stop sign arm has two red flashing amber lights on top and bottom of the stop sign.

In order to ensure safety for all road users, the in-vehicle control computer 150 can be configured to safely interact with any and all detected school buses. For example, the in-vehicle control computer 150 can be configured to maintain a predetermined minimum safe distance when following a school bus as the target vehicle. The predetermined minimum safe distance can include, for example, 75 m, 100 m, 125 m, although other values are also possible.

In some embodiments, the in-vehicle control computer 150 can be configured to pass a detected school bus only when the in-vehicle control computer 150 determines that it is safe to do so. When passing a school bus, the in-vehicle control computer 150 can be configured to change lanes from the lane that the school bus is located in from a predetermined minimum distance away from the school bus. The predetermined minimum distance can include, for example, 75 m, 100 m, 125 m, although other distances are also possible. The in-vehicle control computer 150 can be configured to cancel an attempt to pass a school bus in response to detecting that the school bus’s flashing amber lights are on.

In response to detecting a school bus with flashing lights, the in-vehicle control computer 150 can be configured to reduce the speed of the autonomous vehicle 105 to maintain a predetermined minimum safe distance when travelling in the same direction with the school bus, while staying in the same lane. The predetermined minimum safe distance can include, for example, 75 m, 100 m, 125 m. The in-vehicle control computer 150 can also be configured to reduce the speed of the autonomous vehicle 105 and prepare for a full stop in response to detecting the yellow flashing amber light of the school bus is on.

The in-vehicle control computer 150 can be configured to have a predetermined minimum safe distance from the school bus when the school bus is completely stopped. The predetermined minimum safe distance can include 20 m, 25 m, 30 m, although other values are also possible. The in-vehicle control computer 150 can be configured to pass a school bus when detecting that the school bus has its yellow flashing amber light on if the autonomous vehicle 105 is approaching the school bus from the opposite direction, the roadway has 4 or more lanes, and there is a median or physical barrier between the lanes.

Yellow flashing lights can be used to indicate that the school bus is preparing to stop to load or unload children. Motorists may slow down and prepare to stop their vehicles. A school bus turns its yellow flashing amber light on at least 5 seconds or 100 m before a full stop. This depends on the initial speed of the school bus and posted speed limit of the road. Laws and regulations vary by different states.

In some embodiments, in response to detecting a school bus with its lights on, the in-vehicle control computer 150 can be configured to reduce the speed of and stop the autonomous vehicle 105 completely a minimum number of meters away from the school bus, while staying in the same lane. The minimum number of meters can include, for example, 15 m, 20 m, 25 m, although other distances are also possible. The in-vehicle control computer 150 can be configured to pass a school bus with red flashing amber light on if the autonomous vehicle 105 is approaching the school bus from the opposite direction, the roadway has 4 or more lanes, and there is a median or physical barrier between the lanes.

Red flashing lights and extended stop arms may indicate the bus has stopped and children are getting on or off. Motorists must stop their cars and wait until the red lights stop flashing, the extended stop-arm is withdrawn, and the bus begins moving before they can start driving again.

In some embodiments, the in-vehicle control computer 150 can be configured to stay at a full stop until detecting that the school bus’s red flashing amber lights are turned off, the extended stop arm is withdrawn, and the bus begins moving.

Animal Detection

Another important aspect involved in safely navigating an autonomous vehicle 105 is the detection of and response to animals. The in-vehicle control computer 150 can be configured to detect animals without reliance on the map and including all metadata. In some embodiments, the in-vehicle control computer 150 can be configured to detect animals on the roadway that are larger than an adult coyote (about 7 inches when lying flat). The in-vehicle control computer 150 can be configured to differentiate between a live animal and roadkill.

In response to detecting a large animal on the road moving in any direction or on the roadside and moving towards the road, the in-vehicle control computer 150 can be configured to adjust the maneuvering of the autonomous vehicle 105 to maintain distances longer than the minimum gap until the autonomous vehicle 105 passes the animal. As used herein, large animal may generally refer to an animal that is large enough to cause damage to the autonomous vehicle 105 if impacted at highway speeds, like bears, boars and deer.

In response to detecting a small animal on highways, the in-vehicle control computer 150 can be configured to not respond. As used herein, a small animal may generally refer to an animal that is too small to cause damage to the autonomous vehicle 105 if impacted at highway speeds, like dogs, cats, and birds, etc. In response to detecting a small animal on a surface road, the in-vehicle control computer 150 can be configured to attempt to prevent the autonomous vehicle 105 from impacting with the small animal. If the in-vehicle control computer 150 cannot avoid impact, the in-vehicle control computer 150 can be configured to not respond to the small animal. When unable to react to a small animal, the in-vehicle control computer 150 can be configured to react as described to the Crash Mitigation Strategy section of this disclosure.

In response to detecting a live animal larger than an adult coyote in the autonomous vehicle’s travel lane, the in-vehicle control computer 150 can be configured to reduce the speed of the autonomous vehicle 105 to avoid a collision and blow the city horn to encourage the animal to leave.

Map Taxonomy

In certain embodiments, a digital map with high precision positioning data for roadways and surroundings can be pre-developed and stored in the memory 175 of the in-vehicle control computer or vehicle computer unit (VCU) 150 of the autonomous vehicle 105 shown in FIG. 1 . When the autonomous vehicle 105 traverses from one location to another, the global positioning unit in the vehicle sensor subsystems 144 receives real-time location or GPS data to guide the autonomous vehicle 105 to drive on roadways according to the digital map stored in the memory 175. Visual perception sensors of the vehicle sensor subsystems 144, including one or more camera, radar and LIDAR devices, can continuously generate real time information about road conditions and surroundings (e.g., process 205 in FIG. 2 ). In certain embodiments, these real time road conditions and surroundings data, together with the real time GPS data are transmitted to the in-vehicle control computer 150, as shown in FIG. 2 as process 210. Then, in certain embodiments, the in-vehicle control computer 150 fuses the real time road data and GPS data to describe the real time road condition and location.

Therefore, the map stored in the memory 175 on the in-vehicle control computer 150 has different layers including at least a more permanent layer and a dynamic layer. The permanent map can be updated on a periodic basis as newer versions are transmitted from the oversight system 350, which collects updated map data from all autonomous vehicles 105 connected over the wireless network 370 and fuses the updated map data into the permanent map. For example, if a newly appeared item is present on a roadway for a long enough period, e.g., a traffic sign, the oversight system 350 will decide to add the item into the permanent map. The layer of the dynamic, more temporary map on the in-vehicle control computer 150 is based on the permanent map, and gets improved by what is detected on the road by the vehicle sensor subsystems 144. As such, this dynamic map may contain temporary map elements such as construction zones or lane closures, for example. The operation of the autonomous vehicle 105 takes priority of the dynamic map over the permanent map when driving on the roadways.

Therefore, there are different data streams for mapped data. On one hand, the in-vehicle control computer 150 is continuously fed with real time road conditions data from the vehicle sensor subsystems 144. The in-vehicle control computer 150 then compares the real time perception data with the stored map data from the dynamic map. On the other hand, there are different layers of map data stored on the in-vehicle control computer 150. When the in-vehicle control computer 150 compares the real time road conditions data with the mapped data stored in the memory 175 and sees a discrepancy, the real time road data precepted by the vehicle sensor subsystems 144 takes priority. In certain embodiments, the in-vehicle control computer 150 may decide to update to map data (dynamic map) and to transmit the updated map data to the control center or oversight system 350 via the wireless network 370, as shown in FIG. 3 . The updated map data can then be shared periodically with other autonomous vehicles 105 that are in communication with the oversight system 350. The following sections describe the handling of the in-vehicle control computer 150 of mapped roadway information stored in the memory 175, the detection of real time information using the vehicle sensor subsystems 144, and plans developed to manage special situations. In the context of this disclosure, the digital map is also referred to as the map, and map data is also referred to as map information, data of the map, mapped data, or mapped information.

Safety Area Requirements

In certain embodiments, the digital map stored on the computer memory 175 of the autonomous vehicle 105 was pre-developed and implemented before the operation of the autonomous vehicle 105. In certain embodiments, the map can be refined and updated with newly detected data when the autonomous vehicle 105 traverses on the road. It may be desirable, in certain embodiments, for the map to satisfy certain requirements, e.g., for the minimal risk condition (MRC) requirements for truck maneuver.

The digital map can include safety areas along highways for the autonomous vehicle 105 to stop when necessary. For example, for each off-ramp exit on a highway, there may be at least two safety areas marked on the map within 5 miles from the exit.

In certain embodiments, the safety areas may satisfy the following requirements. First, each safety area can be at least 96 meters (315 feet) long and 3.4 meters (11.2 feet) wide if it is defined by soft boundaries, or 3.6 meters (11.8 feet) wide if it is defined by hard boundaries. This can be advantageous by enabling a vehicle entry speed of 30 miles per hour (MPH), or 48 kilometers per hour (KMPH). Secondly, the safety area can be clear of permanent road hazards with a size bigger than 15 cm (6 inch) in height and wider than the lateral wheelbase of the vehicle. In some embodiments, each carriageway in the safety area may be paved. Further, it may be desirable that the safety area is not located on an overpass bridge. In certain embodiments, the safety area may include areas that do not have a no entry traffic sign and exclude any gore areas. In certain embodiments, the map can be configured to cover surrounding areas, e.g., 280 meters (919 feet), beyond the safety area in a longitudinal direction.

Road Taxonomy

In certain embodiments, roadways are defined and classified according to their types in the map so that different plans can be developed for the autonomous vehicle 105 and different actions can be taken based on pre-developed algorithms. The roadway definitions can conform to the laws and regulations and even customary local rules. The roadway, or road, definitions and/or classifications disclosed herein represent examples, not all, of the instants stored in the map. In the context of this disclosure, definition and classification can be synonyms to each other.

Roadways within the digital map can be defined as mapped roadways.

Drivable roadways within the map may be defined as the areas that a vehicle can occupy, including restricted areas. Example drivable roadways includes roads, lanes of carriageway, and other areas that the autonomous vehicle 105 can drive on.

A limited access highway can be defined as a road type that is designed for high-speed traffic with limited access traffic flow, e.g., a dual carriageway divided by a median strip shown in FIG. 8A which is a photo showing an example of a limited access highway. On the other hand, a non-limited access highway is classified as a road type that is designed for high-speed traffic but is highly accessible.

A local roadway can be defined as a street that accepts traffic from collector roads and distributes traffic through subdivisions, neighborhoods, and business areas in a city, town, or village to homes, apartments, business sites, and industrial sites. An arterial road generally refers to a high-capacity urban road which delivers traffic between collector roads and highways. A collector road may generally refer to a low-to-moderate capacity road which serves to move traffic from local streets to arterial roads. Unlike arterials, in certain embodiments, collector roads can be designed to provide access to residential properties.

A single-lane road may generally refer to a road that permits two-way travel, but is not wide enough in most places to allow vehicles to pass one another. An example of the single-lane road is shown in FIG. 8B where the road is divided into two single-lane roads, one for each driving direction. In comparison, a multi-lane road can be a road that has two or more lanes of traffic traveling in the same direction with no physical barriers separating the lanes. An example of the multi-lane road is illustrated in FIG. 8C. For example, the area defined by a box 802 in FIG. 8C covers approximately three lanes driving in the same direction.

A divided roadway can be classified as a roadway where the lanes of opposing traffic directions are divided by a physical barrier, e.g., a median. An example divided roadway is shown in FIG. 8D. A median is an area in the middle of a divided roadway. The median includes an area between the opposing direction lanes defined by hard or soft boundaries, as shown in FIG. 8D as the area covered by a rectangular box 804.

An undivided roadway is defined as a roadway where the lanes of the opposing traffic directions are separated only by lane marks, but not by physical barrier. FIG. 8B illustrates an example of the undivided roadway.

A one-way road is a road where traffic moves only in a single direction, as shown in FIG. 8E by the one-way traffic sign as an example.

A frontage road is classified as a subsidiary road that is parallel to a highway and provides unrestricted access to local destinations. An example frontage road 806 is schematically presented in FIG. 8F.

An on-ramp, also referred to as an entry ramp, is an interconnecting roadway of a traffic interchange that allows traffic to enter a highway, especially a limited access highway. FIG. 8G provides an example on-ramp 808 from an undivided arterial road 810 a to a limited access highway 812 a. In FIG. 8G, the on-ramp 808 includes the length from a first gore point 810 b on the undivided arterial road 810 a to a second gore point 812 b on the highway 812 a. If roads are marked by dividing lines, the on-ramp starts from the clearance of the intersection on an undivided arterial road 810 a and ends at the dotted merge line on the highway 812 a.

An off-ramp, or an exit ramp, is defined as an interconnecting roadway of a limited access highway that allows a vehicle to exit the highway. As shown in FIG. 8H, an off-ramp 813 a usually starts from a gore point 813 b on the highway and ends at a stop line (not shown) at the end of the ramp or a gore point in absence of the stop line.

As used herein, a gore area may generally refer to a triangular space between the outside lane of a highway and an on-ramp or off-ramp. The gore area can be defined by the white lines painted on the road that meet in a point where the highway and the on-ramp or off-ramp join, and is usually inside a hard boundary or a soft boundary and marked by a few white lines, as schematically illustrated in FIG. 8I. A gore point may be classified as the intersection of two map element lines or barriers. In FIG. 8G, 810 b is shown as a rounded intersection and 812 b is shown as a sharp intersection gore point.

An interchange is defined as a connecting roadway or a junction between two highways. The interchange allows a vehicle to exit from one highway at a first gore point, usually with traffic direction change, and to enter the next highway at a second gore point. The off-ramp and the on-ramp defined in the above paragraphs are examples of interchanges.

A merge area is an area that allows a vehicle to accelerate to the present flow of traffic and merge into the flow of traffic. The merge area starts at a gore point 576 a where two solid white lines intersect and finishes at the point 576 b where the merged lane boundaries are the same width as the surrounding lanes, as shown in FIG. 8J. A local merge area is defined as an area in a local roadway that allows vehicles from two lanes to merge into one lane. The local merge area starts at a gore point where two solid white lines intersect and finishes when the merged lane boundaries are the same width as the surrounding lanes. In FIG. 8K, a local merge is indicated by traffic signs such as left lane ends and merge right.

An emergency lane is defined as a road shoulder that is adjacent to the driving lanes. FIG. 8L is a schematic of a roadway showing an emergency lane 814 c as part of a map extension 814 b. The emergency lane 814 c is outside of a solid lane line 814 a, that marks the edge of the drivable roadway, and is bounded by a hard or soft roadside boundary 814 d. An MRC lane is an emergency lane that can allow the autonomous vehicle 105 to fulfill the first MRC maneuver that may include pulling the vehicle over to a shoulder of the roadway.

A part time shoulder lane is defined as an emergency lane that can be converted to a driving lane during certain hours of the day. FIG. 8M shows an example part time shoulder lane on a divided highway pointed by an arrow light 878. An evaculane is an emergency lane that can also be used as an additional driving lane during an evacuation. In FIGS. 8N-8Q are shown traffic signs indicating that an emergency lane can be used as an evaculane for different evacuation purposes. A temporary bus lane is an emergency lane that serves as a driving lane dedicated to buses.

An intersection is defined as an area where two or more roads converge, diverge, meet, or cross at the same elevation. In other words, at an intersection, multiple roads intersect the area, as shown in FIG. 8R as an example. If an intersection is regulated and controlled by stop signs, the intersection can be referred to as a stop sign intersection. A stop sign intersection can have as many stop signs as the number of the converging drivable roadways, e.g., two-way, four-way, or etc. If an intersection is regulated and controlled by traffic signals, it is a signalized intersection or a traffic signal intersection. A traffic signal intersection includes the area where all drivable roadways are intersecting. A traffic signal is defined as a light signal emitted from a device designed to control the flow of traffic. Moreover, if an intersection is regulated and controlled by yield signs, it is a yield intersection. A yield intersection includes the area where all drivable roads are intersecting.

A T-intersection is classified as an intersection where one road intersects with another at or close to right angle. A T-intersection includes the area where all three roadways intersect. A fork intersection is an intersection where one road splits into two or more roads with traffic flowing in one direction. And a Y-intersection is defined as an intersection where one road splits into two or more roads with traffic flowing in both directions. The fork intersection and the Y-intersection are differentiated by whether traffic flow is in one direction. While a fork intersection has one directional flow of traffic, a Y-intersection has two-way traffic.

A railroad crossing, also referred to as a level crossing, is defined as an intersection area where a railway intersects with a roadway for vehicles. A railroad crossing may include the width of the drivable roadway and the length between the stop lines in both directions.

A primary roadway is a roadway where a vehicle has a right-of-way at an intersection. And a second roadway is a roadway where a vehicle yields a right-of-way at an intersection.

A K-ramp is defined as a sequential combination of an on-ramp, a temporary merge lane, and an off-ramp, wherein the temporary merge is shorter than a predetermined distance. The predetermined distance can be, for example, 1000 meters (3281 ft), although other values are possible. The temporary merge lane is a lane between an on-ramp and an off-ramp that does not end. Such a temporary merge lane is intended to be used by a vehicle to change lane inward or to take the immediate off-ramp to exit the highway, as shown in FIG. 8S.

A driving lane is a road space where vehicles drive under a specific set of rules. A managed lane is a type of highway lane that is operated with a management scheme, such as lane use restrictions or variable tolling, to optimize traffic flow or vehicle throughput, or both. A fast-track toll lane is an express lane with a fully electronic toll system without a toll booth or traffic gate. Only a valid fast track account and a properly mounted and set toll tag are required to use the express lanes. FIG. 8T and FIG. 8U provide two photos showing example express lanes as indicated by the traffic signs. A high-occupancy vehicle (HOV) lane, also known as a carpool lane, diamond lane, 2+ lane, transit lane, T2 lane or T3 lane, is a traffic lane reserved for buses, or vehicles having two or more occupants. These restrictions may be imposed during peak travel times or may apply at all times. Many jurisdictions exempt other vehicles, including motorcycles, charter buses, emergency and law enforcement vehicles, low-emission and other green vehicles for using an HOV lane. FIG. 8V shows an HOV lane entrance on a highway. A high-occupancy toll (HOT) lane is defined as a lane that is available to high-occupancy vehicles and other vehicles that pay a toll to use. FIG. 8W shows a HOT entrance toll station.

A center lane is defined as a single lane located in the middle of a two-way street, in which traffic may travel in either direction or make a left turn. An example center lane 816 is schematically shown in FIG. 8X. The center lane is also referred to as a two-way left turn lane, or TWLT lane.

A dynamic lane is defined as a lane in a roadway that is dynamic in its set of rules based on a time of the day and traffic severity. Dynamic lane assignment strategies repurpose the dynamic lane road space based on a current or expected demand conditions in order to improve the efficiency and safety of the transportation system. A dynamic lane can include reversible lanes on highways and arterials, merge (or junction) control on highway ramps, and part-time highway shoulder use.

A truck-only lane is defined as a lane designated for the use of trucks only. A truck lane is shown in FIG. 8Y. A bicycle lane is a lane on a local roadway that is sectioned off by dotted or solid lines and may have a bicycle symbol, as shown in FIG. 8Z. A bus lane is defined as a division of a road marked with painted lines for use by buses, as shown in FIG. 8AA.

A slip lane is defined as a right turning lane that avoids an adjacent intersection. The slip lane bypasses the intersection by cutting around the intersection and reaches directly to the target lane. A slip lane 818 is schematically illustrated in FIG. 8AB, and another slip lane 820 is shown in FIG. 8AC as an example.

A merge through lane is a straight lane that accepts mergers from a merge ending lane. The merge ending lane is defined as the lane that is merging into the merge through lane, often from an on-ramp onto a highway. A merge through lane 822 and a merge ending lane 824 are shown in FIG. 8AD.

A zipper lane is defined as a merge lane that has no right-of-way taxonomy, e.g., when a lane is temporarily closed.

A hard boundary is defined a vertically elevated surface placed over a terrain. A curb is a type of hard boundary that separates a drivable roadway from non-drivable or pedestrian areas. Curbs are often found adjacent to local drivable roadways that separate the emergency lane from the sidewalk.

A soft boundary is defined as a substantial road boundary that is not a vertically elevated surface. Soft boundaries are usually flat boundaries that, if crossed, would not directly lead to vehicle damage but is not on the drivable roadway and contains higher risk of unstable terrain and damage due to debris or objects.

A sidewalk is a paved pedestrian area on the side of a local roadway that is separated from the drivable roadway. The sidewalk can extend from a curb to a hard or soft boundary. In FIG. 8AE, a sidewalk 826 is defined between a curb 828 and a boundary 830, which can be either a hard boundary or a soft boundary. The sidewalk 826 is part of a map extension 832.

A crosswalk is a pedestrian crossing area that intersects with a drivable roadway. The crosswalk area is classified by spaced horizontal lines or zebra markings, vertical markers, or speed tables, and begins at the curb or boundary on one side of the roadway and ends at the curb or boundary on the other side of the roadway. A crosswalk with spaced zebra markings is shown in FIG. 8AF.

An overpass is defined as a roadway that is vertically elevated over another roadway. Such an overpass is vertically intersecting with the underpass. On the other hand, a bridge is a structure carrying a road, path, railroad, or canal across a river, ravine, road, railroad, or other obstacle. An underpass is defined as a roadway that is vertically underneath another roadway. It is vertically intersecting with an overpass.

The vertical clearance of any mapped, drivable area may be defined as to include at least the height of the highest point of the autonomous vehicle 105 plus a safety buffer. A tunnel is defined as an underground roadway that is enclosed except for the entrance and exit points. FIG. 8AG shows an example of a tunnel with an entrance.

A curved road is defined as any roadway that is not longitudinally straight. The radius of curvature for a curved road is usually 1,124 meters (3,688 ft) or less. An inclined roadway is defined as any roadway that is not vertically level but with a slope.

Unclassified roadways are defined as those which do not fit any other definition within this disclosure and are completely unfamiliar to the autonomous vehicle 105. Therefore, in the digital map stored in the memory 175 of the in-vehicle control computer 150, an unclassified roadway is un-defined and does not have a classification.

An unmarked roadway is defined as a roadway that does not consist of lane lines or markings to regulate the flow of traffic. An unmarked area of a highway is defined as an area adjacent to the highway that is outside of a hard or soft boundary of the emergency lane and is within the map boundary. Referring back to FIG. 8L, an unmarked area 814 e of a highway is defined as the area outside of the boundary 814 d. A local unmarked area is defined as an area adjacent to a local roadway or sidewalk that is unpaved or unmarked. It is the space outside of a hard or soft boundary of the sidewalk, or outside of the curb in absence of a sidewalk. Referring back to FIG. 8AE, a local unmarked area 834 is defined as the area outside of the sidewalk 826 and the boundary 830.

A restricted driving area is any area on a roadway in which the autonomous vehicle 105 is not permitted to drive based on a regulation, control, or speed.

A driveway is defined as a restricted driving area that is the connection of a local destination and a local roadway. A driveway includes the width between the curbs of the roadway and the length to the destination and at least as long as the autonomous vehicle 105. An example driveway 580 is shown in FIG. 8AH, from a local roadway to the gas station in the photo.

A street parking is defined as the shoulder area adjacent to a local driving lane dedicated to parking of vehicles. It is classified as the area from the rightmost lane line, or the closest point of the parking space line in absence of a rightmost lane line, to the curb.

A construction zone is defined as an area in a drivable roadway that is sectioned off for construction purposes, and is limited to the space inside of a virtual wall defined by traffic control devices and traffic signs.

A no truck lane is defined as a lane that prohibits semi-trucks or trucks to drive in. A no truck lane is shown in FIG. 8AI as indicated by the arrow on the white traffic sign board.

A traffic sign is defined as a traffic control instruction giving information to road users. A speed limit is defined as the maximum speed at which road users, including vehicles, may travel on the designated roadway.

A bump is defined as a temporary change in elevation of the roadway. In certain embodiments, the bump has a length no longer than the length of the autonomous vehicle 105.

Besides roadways, in certain embodiments, the digital map covers areas extended beyond roadways. In certain embodiments, the map can extend by at least 6 meters (20 ft) laterally from the edges of the outermost driving lanes. The map may further extend all on-ramps that intersect with the highways that the autonomous vehicle 105 is configured to drive on by up to 300 meters (984 ft) in length. The map may extend all intersection cross traffic roadways by considering the amount of time that the autonomous vehicle 105 will take to complete its maneuver through the intersection, the speed limit at the intersection, and a safety factor of, for example, 1.5. Therefore, in certain embodiments, Map Extension (m) = [Time of autonomous vehicle 105′s intersection maneuver (s)] x [Speed limit at intersection (m/s)] x 1.5.

Moreover, the map may extend all frontage roads that connect to the highways that the autonomous vehicle 105 is configured to drive by up to 300 meters (984 ft) in length and the entire width of the frontage road. The map may extend to the entire roadway of all pre-defined alternative routes.

In certain embodiments, the map extends to cover the entire roadway of all off-route first MRC safety areas that do not vertically intersect with the route plus an additional 400 meter (1312 ft) in length past the end of the last mapped MRC safety area. In certain embodiments, the map may extend the highways that the autonomous vehicle 105 is configured to exit through 400 meter past the nearest MRC safety area.

Roadway Types

When the autonomous vehicle 105 traverses on roadways, it relies on the high-definition digital map information or mapped information stored on the in-vehicle control computer 150 and the global positioning unit on the vehicle sensor subsystems 144 to guide its way. In certain embodiments, the autonomous vehicle 105 can continuously detect road type information with one or more camera, LIDAR and radar devices installed on the vehicle and compare the real time road information, which forms a temporary map, with the mapped information stored on the in-vehicle control computer 150.

For example, the in-vehicle control computer 150 of the autonomous vehicle 105 may detect one way road traffic signs, including one way do not enter traffic signs, at a predetermined minimum distance, e.g., 200 meters, 222 meters, 250 meters, 275 meters, or 300 meters before approaching the target traffic signs. FIG. 8AJ and FIG. 8AK show example of “one way do not enter” and “one way” traffic signs. If the in-vehicle control computer 150 determines that a one-way road is not mapped in the digital map stored in the memory 175, it will take the temporary map based on the detected data as priority over the stored digital map and report the detected information to the oversight system 350 via the wireless network 370 which may transfer the updated map information to other monitored autonomous vehicles 105.

The in-vehicle control computer 150 may make decisions based on the pre-developed plans stored on its in-vehicle control computer 150. For example, if the traffic direction of a one-way road according to traffic sign is in contradiction with the traffic direction stored in the pre-developed map, the control computer 150 may be configured to drive the autonomous vehicle 105 to avoid entering that one-way road. If the in-vehicle control computer 150 detects that another vehicle is driving in the wrong direction on a one-way road, it may decide to perform a safety critical lane change or trigger a first MRC stop if a shoulder is available.

In certain embodiments, the in-vehicle control computer 150 on the autonomous vehicle 105 can be configured to choose to drive on divided roadways if they are available. The in-vehicle control computer 150 can be configured to actively detect vehicles and obstacles present in all lanes of the divided roadway in the driving direction and can take action once an unfavorable situation occurs. If the roadway is an undivided roadway, the autonomous vehicle 105 can actively monitor the vehicles and obstacles present in all lanes of the undivided roadway in its driving direction and the opposite direction.

When the autonomous vehicle 105 approaches a fast-track toll lane, the in-vehicle control computer 150 may determine from the mapped information and the traffic signs perceived by the vehicle sensor subsystems 144 whether the type (e.g., car, truck, etc.) of the vehicle the autonomous vehicle 105 is allowed to drive in the lane. In some embodiments where the autonomous vehicle 105 is configured as a truck, certain fast-track toll lanes may not allow the truck to access the lane. In case the vehicle is not allowed, the in-vehicle control computer 150 may search the map for alternative routes to continue its trip to the destination. If the detected traffic signs and mapped information are in conflict about a fast-track toll lane, the in-vehicle control computer 150 may consider which of the conflicting traffic signs are more prevalent or have a higher priority when making a determination as to the nature of the fast-track lane.

When the in-vehicle control computer 150 of the autonomous vehicle 105 detects a HOV or HOT lane traffic sign, it may determine from the mapped information and the detected traffic signs whether the lane or lanes are restricted for high occupancy vehicles all the time. In the embodiments in which the autonomous vehicle 105 belongs to a type that does not satisfy the requirements to use the HOV or HOT lane, the in-vehicle control computer 150 may plan an alternative route to continue its travel to the destination. If the vehicle is allowed to use the lane(s), the in-vehicle control computer 150 may decide to drive on the lane(s). If the detected traffic signs and mapped data are in conflict about the HOV or HOT lane, the in-vehicle control computer 150 may consider which of the conflicting traffic signs are more prevalent or have a higher priority when making a determination as to the nature of the HOV or HOT lane.

In some embodiments when the autonomous vehicle 105 is a truck and a restricted truck lane traffic sign is detected, the in-vehicle control computer 150 may find an alternative route to continue its journey to the destination.

Roadway Surfaces

Road surfaces may be defined as rough, loose gravel, bridge (parallel stones or grated surfaces), slippery surface types, etc. In certain embodiments, the digital map stored in memory 175 of the in-vehicle control computer 150 of the autonomous vehicle 105 may include road surface metadata on roadway segments. The digital map may also contain undrivable road statistics on road surfaces. Undrivable road statistics are defined as the number of failures detected by the autonomous vehicles 105 connected together by the wireless network 370 attempting to use the road. For example, upon approaching a roadway, the in-vehicle control computer 150 may check the high-definition digital map metadata to verify the conditions of the roadway, including the undrivable statistics. If the roadway is identified as undrivable, the in-vehicle control computer 150 may develop a plan to avoid the roadway if possible.

Besides checking mapped road surface condition data, the in-vehicle control computer 150 may use the vehicle sensor subsystems 144 equipped on the autonomous vehicle 105 to detect or observe road signs for road surface conditions. For example, the in-vehicle control computer 150 may detect unpaved road and pavement end road signs at a predetermined minimum distance, e.g., greater than 200 meters, 250 meters, 300 meters, or 350 meters, before reaching the road signs. The in-vehicle control computer 150 may detect uneven road surface signs at a predetermined minimum distance, e.g., greater than 200 meters, 222 meters, 250 meters, or greater than 275 meters, before approaching the traffic signs. FIG. 8AL and FIG. 8AM show examples of uneven road surface traffic signs. In addition, the in-vehicle control computer 150 may detect auxiliary stop sides using road signs at a predetermined minimum distance, e.g., 200 meters, 222 meters, 250 meters, or 275 meters, before approaching the road signs, as shown in FIG. 8AN, which is a soft shoulder road sign, as an example. The in-vehicle control computer 150 may detect road surfaces using horizontal and vertical markings or traffic signs at a predetermined minimum distance, e.g., greater than 200 meters, 222 meters, 250 meters, or greater than 275 meters, before approaching the traffic signs. FIG. 8AO-5AR are examples of traffic signs for road surface conditions. Furthermore, the autonomous vehicle 105 may detect the road signs for rocks falling on road at a predetermined minimum distance, e.g., greater than 200 meters, 222 meters, 250 meters, or greater than 275 meters, before approaching the traffic signs. FIG. 8AS shows an example rocks-on-road traffic sign.

When an unfavorable road condition is detected by the in-vehicle control computer 150 in conjunction with the vehicle sensor subsystems 144 from reading a road sign, the computer may take actions according to the pre-developed algorithms for selecting alternative routes or to minimize the negative impact.

For example, if rocks are detected on a road, the autonomous vehicle 105 may stop and plan an alternative route to go around the rocks. If an uneven road is detected, the autonomous vehicle 105 may decide that the uneven road is not safe and plan an alternative road to avoid the uneven road. The in-vehicle control computer 150 may also plan an alternative route to avoid a pavement end or unpaved road because an unpaved road may affect the performance behavior of the autonomous vehicle 105. Unpaved roads can create dust for following vehicles and impair road visibility. Once on an unpaved road, the autonomous vehicle 105 may avoid overtaking vehicles in front for safety measures. For example, the autonomous vehicle 105 can prioritize paved lanes when planning a route to destination.

The autonomous vehicle 105 may change speed depending on the road surface conditions. For example, when loose gravel, slippery or rough surfaces are detected for a road segment, the autonomous vehicle 105 may slow down by a predetermined percentage of speed, e.g., by 10%, 15%, or 20% of the speed limit. The autonomous vehicle 105 may plan a lane change or overtaking other vehicles that have sudden movements. In some embodiments, when the autonomous vehicle 105 is a truck, sudden movements can impact the movement of its cargo/load and change the center of gravity of the vehicle. This can increase lateral acceleration and may result in the vehicle crossing the intended lane boundaries.

In other embodiments, if the autonomous vehicle 105 is a truck, the in-vehicle control computer 150 of the vehicle may develop a plan to avoid a drawbridge or bridge lanes with grated surfaces, because grated surfaces may not support heavy trucks. When planning a stop, the autonomous vehicle 105 may use the unpaved soft shoulders in case it is not allowed to stop on the road.

Mapped Construction Zone

In a construction zone, things change progressively and dynamically, so the information in the stored map may not accurately reflect the current road conditions. For example, detection of the current road conditions by the vehicle sensor subsystems 144 becomes important for the safety of the autonomous vehicle 105 and other road users. There are different types of traffic signs for construction zones. And a sign may be held by a person with hand signals to transfer different meanings to the oncoming vehicles. The autonomous vehicle 105 considers a person controlling traffic in a construction zone area as a construction zone flagger. In FIG. 8AT and FIG. 8AU, two construction zone flaggers are shown as examples, each of them holding a stop/slow signaling paddle. A construction zone flagger may use a “stop road users” hand signal to stop vehicles. To do this, the construction zone flagger faces the oncoming traffic and aims a stop paddle held in one hand toward the traffic in a stationary position. The construction zone flagger can hold the free hand above the shoulder level with the palm open and toward the approaching traffic, as shown in FIG. 8AV. To allow the traffic to proceed through the construction zone, the construction zone flagger uses a “proceed road users” hand signal. The construction zone flagger faces the oncoming traffic and aims a slow paddle toward the traffic in a stationary position. Meanwhile his/her free arm extends horizontally away from the body and motions with the free hand for the traffic to move forward, as shown in FIG. 8AW and FIG. 8AX. Another signal is a “slow road users” hand signal. In this case, the construction zone flagger faces the oncoming traffic and aims the slow paddle toward the traffic in a stationary position. At the same time his/her free arm extends horizontally away from the body and moves the free hand up and down with palm down, as shown in FIG. 8AY and FIG. 8AZ.

Since construction zones are progressive and evolving, the autonomous vehicles 105 may actively detect changes with the vehicle sensor subsystems 144, update the digital map, and periodically inform the oversight system 350 through the wireless network 370. The updated information may include construction zone traffic signs, speed limit traffic signs, lane closure traffic signs, and etc. The autonomous vehicle 105 may detect construction zone traffic signs at a predetermined distance, e.g., at 200 meters, 300 meters, or 400 meters from the traffic signs. The types of construction traffic signs may be construction zone signs, as shown in FIG. 8BA-8BD, the lane closure signs, as shown in FIG. 8BE-8BI, the detour signs, as shown in FIG. 8BJ, the speed limit signs, as shown in FIG. 8BK-8BM, and the end of construction zone signs, as shown in FIG. 8BN-8BP. The construction zone traffic signs in the above-mentioned figures are shown as examples. The road devices detected by the autonomous vehicle 105 may include traffic control devices as well. The in-vehicle control computer 150 of the autonomous vehicle 105 may be able to detect the differences of what is perceived from the sensors from what is in the stored map, and transmit the collected real time data to the oversight system 350 over the wireless network 370 once a difference is detected, so that the digital map maintained by the oversight system 350 gets updated. Except the types and locations of the construction zone signs, the real time differences may include lane closure information, speed limit information and lane shift information.

The autonomous vehicle 105 may be able to detect the construction zone flagger’s hand signal devices, as shown in FIG. 8BQ-8BS, and also detect and interpret the construction zone flagger’s hand signaling, including the “stop road users” hand signal, the “proceed road users” hand signal, and the “slow road users” hand signal, as illustrated in FIG. 8BT-8CB. In case that the autonomous vehicle 105 cannot interpret a hand signal from a construction zone flagger, it may decide to stop at least a predetermined distance, e.g., 4 meters, 5 meters, 6 meters, 7 meters, or 8 meters, away from the flagger, although other distances are also possible. The autonomous vehicle 105 may inform the oversight system 350 of the information.

Upon approaching a construction zone according to the map or the detection of the construction zone traffic signs, the in-vehicle control computer 150 of the autonomous vehicle 105 may decide plans and take actions according to the pre-developed algorithms to minimize the negative impact.

For example, when approaching a mapped construction zone, the autonomous vehicle 105 may maintain a predetermined safe distance from traffic control devices. The predetermined safe distance can include, for example, 8%, 10%, or 12% of lane width. When a construction zone traffic sign without a speed limit is detected, the autonomous vehicle 105 may slow down by a margin from its initial speed. The margin can range from 5 MPH to 10 MPH in certain embodiments. When a construction zone speed limit sign is detected, the autonomous vehicle 105 may follow speed limit regulation given by the relevant traffic sign.

If the autonomous vehicle 105 detects a construction zone traffic sign indicating headlight-on, the vehicle may turn on its headlights.

The in-vehicle control computer 150 may actively sense for construction zone flaggers and observe hand signals. If the detected hand signal is a “stop road users”, the autonomous vehicle 105 may plan to stop at a predetermined minimum distance, e.g., at least 5 meters, 6 meters, or 7 meters, from a construction zone flagger. If the hand signal is a “slow road users”, the autonomous vehicle 105 may slow down by a margin from the initial speed, e.g., the margin ranging from 10 MPH to 20 MPH. If the hand signal is a signal for the road users to proceed, the autonomous vehicle 105 may plan to proceed forward.

When a detour traffic sign is detected, the autonomous vehicle 105 may follow the direction indicated by the detour traffic sign. When a construction zone lane closure sign is detected, the autonomous vehicle 105 may plan a critical safety lane change to a lane that is not closed at least a predetermined distance, e.g., 50 meters, 100 meters, or 150 meters, ahead of the lane closure.

In certain situations, the in-vehicle control computer 150 of the autonomous vehicle 105 may decide to send the detected information to the oversight system 350 over the wireless network 370. When construction zone traffic signs are detected, the autonomous vehicle 105 may inform the oversight system 350. When an end of construction zone sign is detected, the autonomous vehicle 105 may also inform the oversight system 350. And the autonomous vehicle 105 may periodically inform the oversight system 350 if there is any change of vertical clearance height within the construction zone. In addition, the autonomous vehicle 105 may continuously inform the oversight system 350 if there is any change of weight limit within the construction zone.

Furthermore, the autonomous vehicle 105 may inform the oversight system 350 if the mapped information is in conflict with the perceived information. For example, when a mapped construction zone is not detected, the autonomous vehicle 105 may inform the oversight system 350. In some embodiments, when a conflict is detected between the mapped and perceived speed limit, the autonomous vehicle 105 may follow the minimum of the regulated speed limit. When a conflict is detected between the mapped and perceived lane shift, the autonomous vehicle 105 may inform the oversight system 350. These conflicts can be categorized as a lane closure and lane shift.

Lane Restriction Navigation

When the autonomous vehicle 105 travels from a starting point to a destination, the in-vehicle control computer 150 may continuously inquire on positioning and road condition data from the map stored in the memory 175 on the in-vehicle control computer 150, and develop plans and take actions for the next segments of roadways based on the pre-developed algorithms. However, the in-vehicle control computer 150 may also control the vehicle sensor subsystems 144, including the plurality of camera, radar and LIDAR devices mounted on the vehicle, to continuously monitor the road conditions. Upon discovery of a difference between the mapped road data and detected road data, the in-vehicle control computer 150 may update the temporary map with the detected road data and transmit the detected data to the oversight system 350 over the wireless network 370.

For example, the in-vehicle control computer 150 may periodically (e.g., continuously in some embodiments) inform the oversight system 350 of the location of HOV lanes, narrow lanes and lane splitting when the detected road information is in conflict with the mapped road data. Other aspects of the detected road data in conflict with mapped data may include any weight limitations on the lane, e.g., as shown in FIG. 8CC-8CG, if the autonomous vehicle 105 is a truck, and the details of ongoing road construction, e.g., as shown in FIG. 8CH-8CQ.

While the autonomous vehicle 105 actively detects and compares road conditions with the data retrieved from the stored map, the autonomous vehicle 105 may focus on certain aspects of the roadways. For example, the autonomous vehicle 105 may detect a narrow lane in advance, or at a predetermined distance, e.g., at least 200 meters, 222 meters, or 250 meters before arriving at the narrow lane. A road narrowing traffic sign is shown in FIG. 8CR. A narrow lane may be defined as a lane narrower than or equal to a predetermined width limit, e.g., 3.25 meters, 3.35 meters, or 3.5 meters wide. The autonomous vehicle 105 may detect the road signs with lane restriction information before approaching the lane restriction location. Examples of road restriction signs are shown in FIG. 8CS-8CU.

In addition, the autonomous vehicle 105 may detect traffic control devices, e.g., cones, lighting devices, markings, barricades, security personals, and etc. A few examples of traffic control devices are shown in FIG. 8CV-8CZ. The autonomous vehicle 105 may establish a virtual wall based on the detected traffic control devices and traffic signs around a construction zone at a predetermined distance, e.g., at least 200 meters, 222 meters, or 250 meters, before arriving at the construction zone. The autonomous vehicle 105 may detect a yield sign or a merge sign at a distance that is longer than the deceleration distance of the autonomous vehicle. An example merge sign is shown in FIG. 8DA.

In addition, in the embodiments when the autonomous vehicle 105 is a truck, the in-vehicle control computer 150 may detect if an available HOV lane allows trucks to pass through.

The autonomous vehicle 105 may develop plans according to the detected road information. For example, when the in-vehicle control computer 150 detects a lane restriction traffic sign, the autonomous vehicle 105 may plan a lane change at a predetermined distance, e.g., at least 200 meters, 222 meters, or 250 meters before arriving at the restriction location. When the in-vehicle control computer 150 detects a lane merge traffic sign, the vehicle may plan to merge into the available lane at a predetermined distance, e.g., at least 200 meters, 222 meters, or 250 meters before arriving at the merging spot.

Example Technique for Updating the Digital Map Based on Real Time Data From the Autonomous Vehicle

In certain embodiments, the digital map stored in the memory 175 on the in-vehicle control computer 150 of the autonomous vehicle 105 was pre-developed. In certain embodiments, the digital map is continuously or periodically updated with real time data collected by the perception sensor on the autonomous vehicle 105. FIG. 8DB illustrates an example method which can be used to update the digital map.

The method 850 begins at block 852. At block 854, the in-vehicle control computer, or the processor, 150 is configured to receive perception data from at least one perception sensor of the autonomous vehicle 105. At block 856, the in-vehicle control computer 150 is configured to generate roadway condition data based on the perception data.

At block 858, the in-vehicle control computer 850 is configured to receive global positioning system (GPS) data from the GPS receiving device of the autonomous vehicle 105. At block 860, the in-vehicle control computer 150 is configured to retrieve mapped data from the memory, or a non-transitory computer readable medium, 175 on the in-vehicle control computer 150 of the autonomous vehicle 105.

Then at block 862, the in-vehicle control computer 150 is configured to determine that the GPS data meets a minimum localization accuracy requirement. When it is determined that the GPS data meets the minimum localization accuracy requirement, at block 864, the in-vehicle control computer 150 is configured to combine the generated road condition data with the GPS data to form detected road data.

At block 866, the in-vehicle control computer 150 is configured to determine that there is a discrepancy between the detected road data and the retrieved mapped data. If a discrepancy between the detected road data and the retrieved mapped data is determined, at block 868, the in-vehicle control computer 150 is configured to update the mapped data with the detected road data, and send the updated mapped data to the remote oversight system through the network communication subsystem. Then the method comes to an at end block 870.

Physical Infrastructure

The autonomous vehicle 105 can be configured to perform a number of different tasks related to the physical infrastructure on or near the roadway. Examples of physical infrastructure that the autonomous vehicle 105 can be configured to detect and respond to include: service stations, terminals (e.g., autonomous freight network terminals), low vertical clearance areas, weigh stations, toll booths, ramp meters, bumps, emergency lanes, roadway widths, and tunnels. In situations where the autonomous vehicle 105 is out of ODD, it can also be important for the autonomous vehicle 105 to perform an MRC. The physical infrastructure can also determine whether an MRC is possible and how the autonomous vehicle 105 should be controlled during an MRC.

In certain embodiments, the autonomous vehicle 105 can determine a minimal risk condition (MRC) maneuver for the autonomous vehicle 105 to execute, identify a safe zone in which the autonomous vehicle 105 is able to execute the MRC maneuver by coming to a stop based on perception data, identify one or more exclusion zones within the safe zone based on the perception data, and control the autonomous vehicle 105 to execute the MRC maneuver including stopping outside of the exclusion zone.

Minimal Risk Condition (MRC) Maneuvers

One important aspect involved in safely navigating an autonomous vehicle 105 is the ability of the autonomous vehicle 105 to perform an MRC maneuver when it is no longer safe for the autonomous vehicle 105 to continue navigation along its current route (e.g., the autonomous vehicle 105 is out of ODD). One aspect involved in successfully executing an MRC maneuver is detecting the local environment of the autonomous vehicle 105. For example, it is desirable that the autonomous vehicle 105 is able to identify regions in which the autonomous vehicle 105 can drive and come to a stop while performing the MRC maneuver, as well as regions in which the autonomous vehicle 105 cannot enter during an MRC maneuver.

In some embodiments, the in-vehicle control computer 150 is configured to establish exclusion zones defining a minimum distance that the autonomous vehicle 105 is configured to stay away from any emergency lane vehicles (ELVs). In some embodiments, the exclusion zones may be included as part of and/or overlap with safe zones (e.g., a shoulder of the roadway).

For example, the in-vehicle control computer 150 can define the exclusion zones to include all areas that are within the predetermined distance in front of or behind any ELV. The predetermined distance can include, for example, 100 meters, although other values are also possible without departing from this disclosure. The in-vehicle control computer 150 is configured to avoid entering the exclusion zones while performing any MRC maneuver, including the first MRC maneuver. Advantageously, by using exclusion zones, the in-vehicle control computer 150 is configured to provide additional risk mitigation to avoid collisions while performing MRC maneuvers.

The in-vehicle control computer 150 can also be configured to avoid completing an MRC maneuver (e.g., avoid stopping the autonomous vehicle 105 after completing an MRC maneuver) when within a threshold distance from a crosswalk at an intersection. The threshold distance can include, for example, 20 feet, although other values are also possible. Advantageously, avoiding completing an MRC maneuver within a threshold distance from a crosswalk can improve safety and risk mitigation to avoid pedestrians while performing the MRC maneuver.

In some embodiments, the in-vehicle control computer 150 can further be configured to avoid completing an MRC maneuver within a threshold distance from a fire hydrant. The threshold distance can include, for example, 4.6 meters (15 feet), although other values are also possible. Because parking next to a fire hydrant is against the law, the autonomous vehicle 105 can be configured to avoid completing an MRC maneuver within the threshold distance from a fire hydrant when possible.

The in-vehicle control computer 150 can also be configured to avoid completing an MRC maneuver within a threshold distance from a flashing beacon or traffic control signal located on the side of the roadway. The threshold distance can include, for example, 9.1 meters (30 feet), although other values are also possible. Parking next to a flashing beacon may be against the law and thus the autonomous vehicle 105 can be configured to avoid completing an MRC maneuver within the threshold distance from a flashing beacon or traffic control signal.

In some embodiments, the in-vehicle control computer 150 can also be configured to avoid completing an MRC maneuver within a threshold distance from a railroad crossing/track. The threshold distance can include, for example, 50 feet, although other distances are also possible. Parking next to a railroad track may be against the law, and thus, the autonomous vehicle 105 can be configured to avoid completing an MRC maneuver within the threshold distance from a railroad track. In order to ensure safety of the autonomous vehicle 105 as well as any nearby road users, the autonomous vehicle 105 is configured to avoid parking on a railroad track for any reason.

When the autonomous vehicle 105 performs an MRC maneuver, the in-vehicle control computer 150 can be configured to provide visual and/or audio notification(s) to an in-cab human machine interface (HMI). For example, the notification can contain information about the type of MRC initiated in response to initiating and/or completing the MRC maneuver. When a driver is present inside the cab of the autonomous vehicle 105, visual and audio notifications can be important for driver feedback as to the autonomous vehicle’s 105 intended MRC maneuver.

The in-vehicle control computer 150 can also be configured to provide notification(s) to the oversight system 350 in response to initiating and/or completing the MRC maneuver. For example, the notification can contain information about the type of MRC initiated in response to initiating and/or completing the MRC maneuver.

In some situations, a chase vehicle may be following the autonomous vehicle 105. In these situations, it can be important for the safety of the autonomous vehicle 105 to provide information regarding any MRC maneuvers that the autonomous vehicle 105 will or is executing. Thus, the in-vehicle control computer 150 can also be configured to provide the notification(s) to the chase vehicle directly and/or via the oversight system 350.

In some embodiments, the in-vehicle control computer 150 can be configured to provide notification(s) on an exterior of the autonomous vehicle 105 in response to initiating and/or completing the MRC maneuver. For example, the in-vehicle control computer 150 can be configured to activate the autonomous vehicle’s 105 hazard lights that are externally visible. In some embodiments, the in-vehicle control computer 150 can be configured to activate the hazard lights in response to reaching the furthest right lane during the first MRC maneuver and keep the hazard lights on after completing the first MRC maneuver. By activating the hazard lights, the autonomous vehicle 105 can notify other road users that that autonomous vehicle 105 is stopped or will soon stop and to help notify the chase vehicle and personnel of the autonomous vehicle’s 105 location.

In certain implementations, the in-vehicle control computer 150 can also be configured to turn on the hazard lights once the autonomous vehicle 105 has reached the furthest right driving lane while performing a first MRC maneuver. The in-vehicle control computer 150 can be configured to keep the hazard lights on until a human operator turns the hazard light off. In some embodiments, during a first MRC maneuver, the usage of the autonomous vehicle’s 105 turn indicator for lane changes between driving lanes supersedes the usage of hazard lights. Thus, the autonomous vehicle 105 can inform other road users of the intended lane changes performed during the first MRC maneuver. Hazard lights can be important notifications to other road users to notify the road users that the autonomous vehicle 105 is performing a safety maneuver to get to a safe area.

When executing an MRC maneuver, the in-vehicle control computer 150 can be configured to maintain a minimum lateral distance between the outer most point of the autonomous vehicle 105 and the lane line that separates the driving lane from the non-driving lane at the closest point of approach when the autonomous vehicle 105 comes to a stop. The minimum lateral distance can include, for example, 0.3 m although other values are also possible. The separation of the autonomous vehicle 105 to the lane line when the autonomous vehicle 105 comes to a stop can provide drivers and passengers of the autonomous vehicle 105 a safe exit while not intruding on any driving lane.

In some embodiments, when executing the first MRC maneuver, the in-vehicle control computer 150 can be configured to control the autonomous vehicle 105 to come to a stop when the autonomous vehicle 105 is completely within the pre-mapped safety area and no part of the autonomous vehicle 105 is intruding into the driving lane. This can be important for the safety of the autonomous vehicle 105 and other road users so that the autonomous vehicle 105 is fully in the shoulder and not blocking oncoming traffic as well as provide the space necessary for any driver or passenger to get out of the autonomous vehicle 105.

In some embodiments, the in-vehicle control computer 150 can be configured to define exclusion zones of construction zones. For example, the in-vehicle control computer 150 can define areas that are within a threshold distance from a construction zone as exclusion zones. The threshold distance can include, for example, 100 meters although other values are also possible. The autonomous vehicle 105 can be configured to avoid entering any exclusion zones. Construction zones can present the risk of pedestrians being present as well as debris that can be damaging to the autonomous vehicle 105.

The in-vehicle control computer 150 can also be configured to avoid completing an MRC maneuver within an intersection. For example, it can be important for the safety of the autonomous vehicle 105 and other road users to avoid blocking traffic in intersections.

The in-vehicle control computer 150 can also be configured to avoid completing an MRC maneuver on a bridge. For example, performing or completing an MRC maneuver on a bridge can present a safety risk to the autonomous vehicle 105 and other road users and thus can be avoided to improve safety.

The in-vehicle control computer 150 can also be configured to avoid completing an MRC maneuver inside of a tunnel. Performing an MRC maneuver inside of a highway tunnel or other tunnel can present multiple safety risks and thus can be avoided to improve safety.

The in-vehicle control computer 150 can also be configured to avoid completing an MRC maneuver within an interchange. Interchanges often have curved roads, which can present a challenge for the autonomous vehicle 105 to come to a stop fully outside of the driving lanes, which can lead to a safety risk.

The in-vehicle control computer 150 can further be configured to avoid completing an MRC maneuver at a location where roadway signs prohibit standing or stopping. For example, completing a first MRC maneuver at a prohibited stopping zone may be against the law and thus should be avoided.

While performing an MRC maneuver, the in-vehicle control computer 150 can be configured to yield to any approaching emergency vehicle that has activated its siren and/or emergency lights. The in-vehicle control computer 150 can further be configured to prioritize a passing emergency vehicle higher than many or most other actions, and thus, the in-vehicle control computer 150 can be configured to yield to emergency vehicles during an MRC maneuver for safety reasons.

The in-vehicle control computer 150 can also be configured to receive an input from a driver behind the wheel of the autonomous vehicle 105 to cancel an MRC maneuver. A driver takeover can improve safety by enabling the driver to control the autonomous vehicle 105 when the driver has determined that performing the MRC maneuver is not necessary and/or would impact safety for the autonomous vehicle 105 or other road users.

The in-vehicle control computer 150 can also be configured to receive an input from the oversight system 350 to trigger an MRC maneuver. By providing for oversight system 350 control, the in-vehicle control computer 150 can improve safety in cases where an MRC maneuver is desirable but may not have been triggered by the autonomous vehicle 105 itself.

In some embodiments, the in-vehicle control computer 150 can also be configured to maintain the autonomous vehicle 105 at a minimum speed when entering a safe area during an MRC maneuver. The minimum speed can include, for example, 30 mph, although other minimum speeds are also possible. The in-vehicle control computer 150 can be configured to maintain the autonomous vehicle 105 at the minimum speed when entering a safe area during an MRC maneuver unless certain external circumstances prevent the autonomous vehicle 105 from doing so. By maintaining the minimum speed, for example on a freeway, the autonomous vehicle 105 can prevent certain types of safety risks to any vehicles located behind the autonomous vehicle 105 and to provide the speed necessary for the autonomous vehicle 105 to complete any lane changes associated with the MRC maneuver.

In some embodiments, the in-vehicle control computer 150 can also be configured to maintain the autonomous vehicle 105 at maximum speed when entering a safe area during an MRC maneuver. The maximum speed can include, for example, 50 mph although other maximum speeds are also possible. Based on the length parameter associated with many safe zones, it is desirable to set a maximum speed such that the autonomous vehicle 105 is able to come to a complete stop within the length of the safe zone.

The in-vehicle control computer 150 can also be configured to classify lane changes triggered based on performing a first MRC maneuver to be a non-critical safety maneuver. Thus, the in-vehicle control computer 150 can also be configured to deny lane changes due to other actions (e.g., safety deniers) with priorities equal or higher than non-critical safety lane changes. The in-vehicle control computer 150 can also be configured to have an exception such that the lane change cannot be denied by a slow moving vehicle. In some implementations, the in-vehicle control computer 150 may not classify the first MRC maneuver as a safety critical maneuver because the autonomous vehicle 105 may still yield for emergency vehicles and prioritize critical safety deniers.

The in-vehicle control computer 150 can also be configured to trigger a first MRC maneuver in response to determining that the autonomous vehicle 105 is approaching the boundary of the map. The in-vehicle control computer 150 can also be configured to execute the first MRC maneuver in response to approaching the boundary of the map as long as a safe zone can be located within the map boundary. In some implementations, the in-vehicle control computer 150 can also be configured to avoid the autonomous vehicle 105 reaching the map boundary for safety reasons.

FIG. 9A illustrates an example visualization of a first MRC maneuver for an example scenario where there are no external complications. In one example scenario in which there are no external complications, the in-vehicle control computer 150 can also be configured to identify an issue that triggers the first MRC, send visual and audio notification in cabin and on the HMI, turn on the autonomous vehicle’s 105 turn signals, and initiate the first MRC command. The in-vehicle control computer 150 can also control the autonomous vehicle 105 to perform one lane change at a time, lane change into a far right lane, and turn on the hazard lights. The in-vehicle control computer 150 can further search for the nearest MRC safe zone, verify that the MRC safe zone is not an exclusion zone and is not blocked, pull the autonomous vehicle 105 over to the safe zone, and control the autonomous vehicle 105 to come to a complete stop within safe zone boundaries. Thereafter, the in-vehicle control computer 150 can also be configured to control the autonomous vehicle 105 to keeps the hazard lights on and send notifications to the in-cabin HMI and to the oversight system 350.

FIG. 9B illustrates an example visualization of a first MRC maneuver for a first example scenario in which the autonomous vehicle 105 is performing a left lane change. FIG. 9C illustrates an example visualization of a first MRC maneuver for a second example scenario in which the autonomous vehicle 105 is performing a left lane change. The in-vehicle control computer 150 can be configured to cancel a left lane change when performing a first MRC maneuver, except if the left lane change is classified as a critical lane change.

In the first example scenario, the in-vehicle control computer 150 can initiate a left lane change. The in-vehicle control computer 150 can trigger a first MRC maneuver, assess localization of the autonomous vehicle 105 with respect to the lane lines, and verify that the centroid of the autonomous vehicle 105 has not crossed the lane line into the target lane of the left lane change. In response to verifying that the centroid of the autonomous vehicle 105 has not crossed the lane line into the target lane, the in-vehicle control computer 150 can abort a lane change (unless the lane change is classified as critical), return the autonomous vehicle 105 back to its current lane, complete the lane change abortion, and initiate the first MRC maneuver.

In the second example scenario, the in-vehicle control computer 150 can initiate a left lane change. The in-vehicle control computer 150 can trigger a first MRC maneuver. The in-vehicle control computer 150 can assess localization of the autonomous vehicle 105 with respect to the lane lines and verify that the centroid of the autonomous vehicle 105 has crossed the lane line into the target lane. In response to verifying that the centroid of the autonomous vehicle 105 has crossed the lane line into the target lane, the in-vehicle control computer 150 can control the autonomous vehicle 105 to complete lane change and initiate the first MRC maneuver.

FIG. 9D illustrates an example visualization of a first MRC maneuver for an example scenario in which the autonomous vehicle 105 is performing a right lane change. Since a right lane change moves in the direction of the first MRC maneuver, the in-vehicle control computer 150 can be configured to avoid cancelling the lane change before triggering the first MRC maneuver. In the example scenario, the in-vehicle control computer 150 can initiate a right lane change, trigger a first MRC maneuver, control the autonomous vehicle 105 to complete the lane change, and initiate the first MRC maneuver.

FIG. 9E illustrates an example visualization of a first MRC maneuver for an example scenario in which the safe area is taken or occupied. When the safe area is taken or otherwise obstructed, the autonomous vehicle 105 may not be able to use the safe area and the in-vehicle control computer 150 can mark the safe area as blocked. In one example scenario, the in-vehicle control computer 150 can trigger a first MRC maneuver, initiate the first MRC maneuver, and control the autonomous vehicle 105 to change lanes into the far right lane. The in-vehicle control computer 150 can also search for the nearest MRC safe zone, locate the nearest MRC safe zone, verify that the MRC safe zone is blocked, and continue controlling the autonomous vehicle 105 to drive to the next safe zone.

FIG. 9F illustrates an example visualization of a first MRC maneuver for an example scenario in which an ELV is located in the safe zone. The in-vehicle control computer 150 can be configured to apply restrictions and design goals with respect to the proximity of the autonomous vehicle 105 to an ELV when completing a first MRC maneuver and pulling over into a safe zone. The restrictions and design goals generally refer to a minimum distance from the autonomous vehicle 105 to the ELV for the autonomous vehicle 105 to be able to use the safe zone in which the ELV is located. As described herein, the autonomous vehicle 105 is configured to come to a complete stop with a sufficient distance between the autonomous vehicle 105 and the ELV. In one example scenario, the in-vehicle control computer 150 can trigger a first MRC maneuver, initiate the first MRC maneuver, and control the autonomous vehicle 105 to change lanes into the far right lane. The in-vehicle control computer 150 can search for the nearest MRC safe zone, locate the nearest MRC safe zone, and verify that an ELV is in the safe zone. The in-vehicle control computer 150 can verify that there is sufficient space to pull into the safe zone and control the autonomous vehicle 105 to complete the first MRC maneuver at least a predetermined distance (e.g., 100 m) away from an ELV.

FIG. 9G illustrates an example visualization of a first MRC maneuver for an example scenario in which the autonomous vehicle 105 is approaching a map boundary. For example, the in-vehicle control computer 150 can be configured to determine that the autonomous vehicle 105 is approaching a map boundary, and in response, determine that the autonomous vehicle 105 should execute the first MRC maneuver. In one example scenario, the in-vehicle control computer 150 can determine that the autonomous vehicle 105 is approaching a map boundary, assess route options, verify that the autonomous vehicle 105 will hit the map boundary, and search for the nearest safe zone. The in-vehicle control computer 150 can locate the nearest safe zone, verify that the safe zone is within the map boundary, and trigger the first MRC maneuver. The in-vehicle control computer 150 can initiate the first MRC maneuver, control the autonomous vehicle 105 to complete the first MRC maneuver, and contact the oversight system 350.

FIG. 9H illustrates an example visualization of a first MRC maneuver for an example scenario in which the autonomous vehicle 105 has missed an exit. When the autonomous vehicle 105 has missed its exit, the autonomous vehicle 105 may determine that performing a first MRC maneuver is the correct course of action. In one example scenario, the in-vehicle control computer 150 can determine that the autonomous vehicle has missed its exit, attempt to reroute the autonomous vehicle 105, and determine that there is not a feasible reroute to the destination. The in-vehicle control computer 150 can trigger the first MRC maneuver, initiate the first MRC maneuver, control the autonomous vehicle 105 to complete the first MRC maneuver, and contact the oversight system 350.

FIG. 9I illustrates an example visualization of a first MRC maneuver for an example scenario in which the autonomous vehicle 105 has been forced off route. The autonomous vehicle 105 may be forced off route for a variety of reasons including most commonly due to road closures. In one example scenario, the in-vehicle control computer 150 can determine that the autonomous vehicle 105 is forced off route, attempt to reroute the autonomous vehicle 105, and determine that there is not a feasible reroute to the destination. The in-vehicle control computer 150 can trigger a first MRC maneuver, initiate the first MRC maneuver, control the autonomous vehicle 105 to complete the first MRC maneuver, and contact the oversight system 350.

Service Station Detection

It is desirable for the in-vehicle control computer 150 to be able to detect service stations or terminals. For example, in the event that the autonomous vehicle 150 is still drivable but has one or more equipment failures that can be addressed by a service station or a terminal, the in-vehicle control computer 150 can be configured to route the autonomous vehicle 150 to a service station or a terminal to obtain repairs or services.

As used herein, a service station may generally refer to a facility that can provide qualified service to the autonomous vehicle 150. Qualified service can include qualified personnel as well as qualified equipment to properly diagnose, and if advisable, fix any failures of the autonomous vehicle 105.

The in-vehicle control computer 150 may store a map within the memory 175 that includes a map of the roadways and nearby environment (see the Map Taxonomy section of this application). The map can include information of known service stations available for the autonomous vehicle 105. The map can further include known services available at each of the stored service stations. The autonomous vehicle 105 and/or the oversight system 350 may periodically (continuously in certain embodiments) update service station locations and available services information stored in the map.

The in-vehicle control computer 150 can be configured to evaluate the type of a detected failure in order to determine the failure severity level (e.g., the level of criticality). In the event of a malfunction or failure, the in-vehicle control computer 150 can request the oversight system 350 to run diagnostic checks to determine the failure severity level. In response, the in-vehicle control computer 150 can trigger an appropriate MRC maneuver or plan a visit to the nearest service station based on the failure severity level.

In response to determining that the failure severity level is less than a predetermined level (e.g., non-critical) and the closest service station is within a predetermined distance, the in-vehicle control computer 150 can be configured to plan a new route to visit the closest service station. For example, the in-vehicle control computer 150 can be configured to determine that a failure is a non-critical failure when the check engine tell-tale is on. As another example, the in-vehicle control computer 150 can be configured to determine that a failure is a critical fault when the check engine tell-tale is blinking. Some examples of non-safety critical failures include: a tire is starting to deflate, and the tire is not part of the steering system, a low coolant alarm, and oil pressure too high/too low.

In response to determining that the failure severity level is less than a predetermined level (e.g., non-critical) and the closest service station is farther than the predetermined distance, the in-vehicle control computer 150 can be configured to plan to park itself on the shoulder (e.g., a safe area) or in an available truck parking lot and notify the oversight system 350.

In response to determining that a failure severity level is greater than a predetermined level (e.g., a critical failure), the in-vehicle control computer 150 can be configured to report to the oversight system 350 that a visit to a service station is required.

The in-vehicle control computer 150 can be configured to detect a service station from relevant traffic signs at a predetermined minimum distance from the service station facility. The predetermined minimum distance can include 200 m, 222 m, 250 m, 300 m, although other values are also possible. FIGS. 9J-9L illustrate example visualizations of service station signs.

The in-vehicle control computer 150 can also be configured to detect if a service station is closed at a distance greater than a predetermined number of meters. The predetermined number of meters can include, for example, 200 m, 222 m, 250 m, although other values are also possible. FIGS. 9M-9N illustrate example visualizations of service station signs indicating that a service station is either open or closed.

The in-vehicle control computer 150 can further be configured to follow the instructions given by traffic signs within the service station facility. The in-vehicle control computer 150 can also be configured to detect and follow instructions of traffic signs in the service station. FIG. 9O illustrates an example visualization of a service station that can include one or more signs having instructions. FIGS. 9P-9R illustrate example visualizations of signs that can be located in a service station.

In some embodiments, the in-vehicle control computer 150 can be configured to detect obstacles like cone markers, pedestrian, toolboxes, etc. in the autonomous vehicle’s 105 trajectory while navigating through a service station. The in-vehicle control computer 150 can further be configured to wait for the autonomous vehicle’s 105 turn and allow other vehicles in front to complete their service at designated parking areas. FIG. 9S illustrates an example visualization of one or more queues at a service station.

The in-vehicle control computer 150 can be configured to detect parking lines at a service station and park the autonomous vehicle 105 within the parking lines. The in-vehicle control computer 150 can also be configured to report to the oversight system 350 after the autonomous vehicle 105 is parked at the service station and then turn the autonomous vehicle’s 105 engine off.

The in-vehicle control computer 150 can be configured to detect traffic conditions and move the autonomous vehicle 105 forward towards the service station keeping a predetermined distance range of following distance from the lead vehicle. The predetermined distance range can include, for example, at least 2 m and no more than 4 m, at least 1.5 m and no more than 4.5 m, at least 1 m and no more than 5 m, although other ranges are also possible.

In some embodiments, the in-vehicle control computer 150 can also be configured to ensure safe departure of the autonomous vehicle 105 from the service station booth by detecting that there are no pedestrian approaching or obstacles present in the departure trajectory.

The in-vehicle control computer 150 can further be configured to detect if a yield sign is present for vehicles leaving the service station booth and yield for vehicles that are merging with the autonomous vehicle’s 105 trajectory path.

Low Vertical Clearance

Another type of physical infrastructure that the autonomous vehicle 105 can be configured to detect includes low vertical clearance objects/areas. Low vertical clearance areas may not have sufficient clearance for the autonomous vehicle 105 to proceed along its route, and thus, it is important for the autonomous vehicle 105 to detect such areas to avoid hitting any low clearance objects.

As used herein, vertical clearance may generally refer to a minimum distance between the drivable pavement of the road and the lowest point of any object located above the drivable pavement. FIG. 9T illustrates an example visualization of a bridge which has a vertical clearance. In addition, low vertical clearance may generally refer to a vertical distance that is lower than the maximum height of the trailer or truck height added to a predetermined number of meters. The predetermined number of meters can include, for example, 0.3 m, 0.5 m, 0.75 m, although other values are also possible.

The in-vehicle control computer 150 may store a map within the memory 175 that includes a map of the roadways and nearby environment (see the Map Taxonomy section of this application). The map can include information regarding signs that indicate bridges and other structures along with their corresponding vertical clearances. FIGS. 9U-9X illustrate example visualizations of signs that may indicate the presence of a low clearance area or object ahead. In some embodiments, the map can include the location, type, and/or vertical clearance of any object above the drivable pavement. The map can be periodically (e.g., continuously in certain embodiments) updated if there is a change of vertical clearance of any object, for example, dur to the presence of a construction zone.

The in-vehicle control computer 150 can be configured to detect vertical clearance information from relevant traffic signs at a predetermined distance. The predetermined distance can include, for example, 222 m, although other distances are also possible without departing from this disclosure.

The in-vehicle control computer 150 can also be configured to monitor the vertical clearance of any object with a distance greater than the distance necessary to stop the vehicle with a deceleration of less than a predetermined deceleration. The predetermined deceleration can include, for example, 2.5 m/s², although other values are also possible.

In some embodiments, the in-vehicle control computer 150 can be configured to plan a route such that all vertical clearances are higher than the low vertical clearance threshold value. The in-vehicle control computer 150 can use the vertical clearance information from the map in planning the route. The in-vehicle control computer 150 can also be configured to plan a new route in the case that there is any vertical clearance lower than vertical clearance threshold value, for example, detected when the autonomous vehicle 105 approaches the low vertical clearance object.

In response to detecting a low vertical clearance on the current path, the in-vehicle control computer 150 can be configured to slow the autonomous vehicle 105 down by a margin from the initial speed to give a more accurate measurement of the vertical clearance. The margin can include, for example a range from 5 mph to 15 mph less than the initial speed, although other values are also possible.

The in-vehicle control computer 150 can be configured to inform the oversight system 350 of a detected vertical clearance location along with the corresponding height in response to detecting a vertical clearance on the current path of the autonomous vehicle 105. The in-vehicle control computer 150 can be configured to stop the autonomous vehicle 105 before arriving at the low vertical clearance location if no new route is possible with a clearance greater than the low vertical clearance threshold value. The in-vehicle control computer 150 can be configured to inform the oversight system 350 in the case that the autonomous vehicle 105 is stopped because of low vertical clearance.

Weigh Station

Another type of physical infrastructure that the in-vehicle control computer 150 can be configured to detect is a weigh station. Certain laws may request the autonomous vehicle 105 be weighed at weigh stations at certain times. Thus, it is desirable that the in-vehicle control computer 150 can detect and navigation weigh stations to comply with applicable laws.

In some embodiments, the in-vehicle control computer 150 can be configured to detect weigh station vertical signals at a distance greater than a predetermined distance to recognize the type of the weigh station. The predetermined distance can include, for example, 75 m, 100 m, 125 m, 150 m, although other distances are also possible. In some implementations, the weigh station type can include either classic or automatic. The distance between a weigh station signal and the weigh station exit may be greater than 800 ft and less than one mile. FIG. 9Y-9AB illustrate example visualizations of signs that may indicate the presence of a weigh station ahead.

The in-vehicle control computer 150 can be configured to detect a closed weigh station at a distance greater than a predetermined distance. The predetermined distance can include, for example, 75 m, 100 m, 125 m, although other distances are also possible. In some cases, a weigh station may be open when a screen with the word “closed” or the text “not open” is shown. In some embodiments, out on the highway bypass program transponders and mobile apps can have the ability to relay the safety record and credentials of the autonomous vehicle 105 and its fleet to the weigh station. When the autonomous vehicle 105 pulls into a weigh station, cameras can read the license plate number of the autonomous vehicle 105. FIG. 9AC-9AE illustrate example visualizations of signs and signals that may indicate whether a weigh station is open or closed.

When approaching an automatic weigh station, the in-vehicle control computer 150 can be configured to detect the state of the weigh station status signal at a distance greater than a predetermined distance. The predetermined distance can include, for example, 75 m, 100 m, 125 m, 150 m, although other distances are also possible. The state can include an indication of the validity of the weigh station. In some embodiments, validity generally refer to whether the traffic signal is green (e.g., valid) or red (e.g., invalid). A validation signal may generally refer to a traffic signal with green and red lights.

When approaching an automatic weigh station, in response to detecting that the validation signal is invalid and weigh station is closed, the in-vehicle control computer 150 can be configured to continue on its route without stopping at the weigh station.

In some embodiments, when driving on a highway, the in-vehicle control computer 150 can be configured to detect the flashing light on top of a vertical weigh station signal at a distance greater than a predetermined distance to plan to enter weight station. The predetermined distance can include, for example, 75 m, 100 m, 125 m, 150 m, although other distances are also possible. One convention/rule on weigh station is that a truck may exit towards a weigh station when a flashing light is on. There are other US states where the rule is that “All trucks must enter the scales when NOT flashing”. The in-vehicle control computer 150 can be configured to use the detection of the flashing light as a decision point to enter the weigh station.

In response to detecting the flashing light of a weight station is detected and determining that the flashing signal is on, the in-vehicle control computer 150 can be configured to enter the weight station.

When at an automatic weigh station and approaching a weigh-in-motion scale, the in-vehicle control computer 150 can be configured to slow the autonomous vehicle 105 down to a predetermined speed range. The predetermined speed range can include, for example, between 12 mph to 60 mph, although other ranges are also possible.

When at a weigh station, the in-vehicle control computer 150 can be configured to bypass a weight check if the check is valid as indicated by flashing green light signal or display with status check.

The in-vehicle control computer 150 can be configured to comply with a dimensions check. For example, no out-of-size cargo may be allowed for some pit stops/gates. Weigh station includes: real-time verification of vehicle dimensions-integrate additional sensors (e.g., gantry-mounted laser over height detectors) to determine if a commercial vehicle exceeds legal height, width, and length regulations and therefore would require an oversize/overweight permit.

When at the automatic weigh station and in case of any malfunction with the autonomous vehicle 105 or the weigh check validation signal is not deterministic, the in-vehicle control computer 150 can be configured to inform the oversight system 350 and wait at the weigh station for next instruction or the remote operator to take over control of the autonomous vehicle 105.

The in-vehicle control computer 150 can be configured to control the autonomous vehicle 105 to comply with the traffic rules as indicated by traffic signs in weigh station area. The in-vehicle control computer 150 can be configured to control the autonomous vehicle 105 to comply with the safety-margins. As used herein, safety-margins may generally refer to a distance from street lines, cars, pedestrians, or any object on the road.

Toll Booth

Yet another type of physical infrastructure that can be detected by the in-vehicle control computer 150 is a toll booth. In some embodiments, the in-vehicle control computer 150 can be configured to identify and autonomously navigate toll booths. As used herein, a toll booth facility or toll booth plaza may generally refer to an area in which the toll booths are located to collect a toll (manually or electronically) from vehicles in transit.

In some embodiments, the in-vehicle control computer 150 can be configured to identify the start or entrance point of a toll booth facility based on detecting where the normal highway lanes start to spread out into multiple toll lanes or the distance to the toll booth is indicated by a traffic sign. The in-vehicle control computer 150 can be configured to identify the end point of a toll booth facility where the multiple toll lanes start to merge into the normal highway lanes. In some cases, toll booth facilities may not spread into multiple lanes. In such cases, the in-vehicle control computer 150 can be configured to identify the starting and end points of the toll booth facilities from the traffic signs that indicate the toll booth speed limit at the beginning of the approach zone and the new speed limit at the end of the departure zone. FIG. 9AF-9AI illustrate example visualizations of toll booth facilities.

The in-vehicle control computer 150 can be configured to detect traffic signs indicating when a toll booth is closed. FIG. 9AJ-9AL illustrate example visualizations of toll booth facilities including traffic signs indicating whether the corresponding toll booths are open or closed.

The in-vehicle control computer 150 can also be configured to detect a toll booth traffic sign and begin slowing down at a predetermined minimum distance before reaching the toll booth facility. The predetermined minimum distance can include, for example, 525 m, 555 m, 575 m, 600 m, although other values are also possible. In some embodiments, the in-vehicle control computer 150 can be configured to use maps and traffic signs to identify all the toll booths within the autonomous vehicle’s 105 route. FIG. 9AM-9AP illustrate example visualizations of a map and signs that indicate the presence of toll booths.

The in-vehicle control computer 150 may store a map within the memory 175 that includes a map of the roadways and nearby environment (see the Map Taxonomy section of this application). The map can include information including traffic sign locations for toll booth facilities within the path of the autonomous vehicle 105. The in-vehicle control computer 150 can be configured to use the map and traffic signs to identify the toll booths within the autonomous vehicle’s 105 route.

The in-vehicle control computer 150 can further be configured to reduce the speed of the autonomous vehicle 105 gradually according to the toll booth’s speed limit. The in-vehicle control computer 150 can also be configured to use the autonomous vehicle’s 105 engine break as first option to slow down.

In some embodiments, the in-vehicle control computer 150 can be configured to select a toll lane according to the autonomous vehicle’s 105 toll payment type at least a predetermined distance from the toll booth. The predetermined distance can include 50 m, although other distances are also possible. An example of automatic payment type is toll pass electronic toll collection (ETC). The in-vehicle control computer 150 can be configured to limit lateral dynamics of the autonomous vehicle 105 based on lateral maneuvers (e.g., lane change, lane bias, curbs) depending on the inertia of the trailer and stability criteria. FIG. 9AQ-9AR illustrate example visualizations of signs indicating the toll payment types accepted by a corresponding toll lane.

The in-vehicle control computer 150 can be configured to detect obstacles in the autonomous vehicle’s 105 trajectory towards the toll booth. The in-vehicle control computer 150 can be configured to wait for other vehicles to leave the toll booth before the autonomous vehicle 105 enters the toll booth.

The in-vehicle control computer 150 can be configured to keep a following distance for the autonomous vehicle 105. For example, the in-vehicle control computer 150 can be configured to make a prediction on the expected target lane front vehicle deceleration, if any. The in-vehicle control computer 150 can be configured to determine a critical distance with the target front vehicle as the largest gap from the following options: 1) the bumper-to-bumper gap required to maintain a high confidence in our sensor coverage, 2) the bumper-to-bumper gap required to be outside of our response time minimums, and 3) the bumper-to-bumper gap required to avoid a collision under the assumption that both the autonomous vehicle 105 and the target lane front vehicle have to decelerate to a complete stop at the expected deceleration of the target lane front vehicle and the autonomous vehicle’s 105 expected reactive deceleration. This gap may account for the autonomous vehicle’s 105 reaction time and may include an additional safety buffer. In some embodiments, if the target front vehicle is not expected to decelerate, this gap may be equal to the safety buffer. The in-vehicle control computer 150 can be configured to maintain a predetermined minimum distance in this situation.

In some embodiments, the in-vehicle control computer 150 can be configured to avoid a lane change within the critical distance to the target lane front vehicle. For all but critical safety lane change intentions, the in-vehicle control computer 150 can be configured to prefer to change lanes with a bumper-to-bumper gap of at least a predetermined distance with the target front vehicle, follow a deceleration behavior, and avoid lane changes behind a target front slow-moving vehicle. The predetermined distance can include, for example, 10 meters, 12.5 meters, 15 meters, 17.5 meters, 20 meters, although other values are also possible. FIG. 9AS illustrates an example visualization of a front distance between the autonomous vehicle and a target lane front vehicle.

In response to determining that a toll gate is closed, the in-vehicle control computer 150 can be configured to control the autonomous vehicle 105 to a full stop at a predetermined distance from the toll gate. The predetermined distance can include, for example, 1 m, 2 m, 3 m, although other values are also possible.

The in-vehicle control computer 150 can be configured to increase the speed of the autonomous vehicle 105 after passing the toll gate with a predetermined acceleration until the allowed speed limit is reached. The predetermined acceleration can include, for example, 1 m/s2, 1.5 m/s2, 2 m/s2, although other values are also possible.

The in-vehicle control computer 150 can be configured to confirm the toll payment has been registered and report any issue with the payment immediately to the oversight system 350. The in-vehicle control computer 150 can be configured to identify the lane indicated by the map to continue the trip.

FIG. 9AT illustrates an example visualization of a toll booth facility. It may be common to find that toll lanes are altered 902, then after toll gate 904 the lanes are restored and start again 906. Also, it may be common to find some toll lanes are out of service, shut down for maintenance and construction or due to accidents, etc.

The in-vehicle control computer 150 can be configured to ensure a safe departure from the toll booth by ensuring there is no other entities/objects like a toll gate or vehicles are blocking the autonomous vehicle’s 105 path.

In response to determining that a lane change is required while navigating the toll booth facilities, the in-vehicle control computer 150 can be configured to control the autonomous vehicle 105 to perform a lane change.

The in-vehicle control computer 150 can be configured to detect and avoid collisions between the autonomous vehicle 105 and any pedestrians, obstacles, and vehicles, within the toll booth facilities, by keeping a predetermined safe distance from these items. The predetermined safe distance can include, for example, 1 m, 2 m, 3 m, although other values are also possible. For example, the autonomous vehicle 105 can avoid running over a pedestrian or toll booth attendant.

In some embodiments, the in-vehicle control computer 150 can be configured to detect if a yield sign is present or if yielding is required for other vehicles that are also leaving the toll booth. The ETC lanes with favorable geometry typically allow vehicles to move through the toll plaza without stopping, but usually within a set regulatory speed limit or advisory speed. The in-vehicle control computer 150 can be configured to resume the trip for the autonomous vehicle 105 until the blocking obstacle, vehicle or pedestrian has been cleared from the autonomous vehicle’s 105 trajectory.

Ramp Meter

Still yet another type of physical infrastructure that the in-vehicle control computer 150 can detect are ramp meters. As used herein, ramp meters may generally refer to traffic signals installed on freeway on-ramps to control the frequency at which vehicles enter the flow of traffic on the freeway. There may be at least two kind of ramp meters: pre-timed controlled and traffic controlled ramp meters.

As used herein, pre-timed controlled may generally refer to time-of-day or fixed time ramp meters. In such case, ramp meters can be activated based on pre-set schedules. Such meters are either showing a steady green light or are turned off.

As used herein, traffic controlled ramp meters may establish metering rates based on actual freeway conditions. FIG. 9AU illustrates an example visualization of a ramp with a ramp meter.

The in-vehicle control computer 150 may store a map within the memory 175 that includes a map of the roadways and nearby environment (see the Map Taxonomy section of this application). The map can include information regarding ramp meters’ location and traffic signs related to ramp meters. FIG. 9AV-9AZ illustrate example visualizations of signs that can indicate the presence of a ramp meter.

The map can further include information regarding a ramp meter’s flow control scheme. The flow control scheme can define the number of vehicles allowed to drive on the ramp when the green light is on. For example, one vehicle may be allowed per green, two vehicles may be allowed per green, one vehicle may be allowed per green each lane. FIG. 9BA-9BC illustrate example visualizations of signs that can indicate flow control schemes.

The in-vehicle control computer 150 can be configured to detect ramp meter ahead signs and whether there is a flashing light to warn that the ramp meter is in operation. When a flashing light is present, the light blinking may indicate that the ramp meter is in operation and the light being off may indicate that the ramp meter is not in operation. FIG. 9BD-9BE illustrate example visualizations of signs and/or flashing lights that can indicate the presence of a ramp meter.

The in-vehicle control computer 150 can also be configured to detect ramp meter traffic lights and the flow control scheme signs. FIG. 9BF-9BI illustrate example visualizations of signs and/or flashing lights that can indicate the presence of ramp meter traffic lights and flow control schemes.

In some embodiments, the in-vehicle control computer 150 can be configured to control the autonomous vehicle 105 to slow down at a predetermined distance from the ramp lights, travel at a speed of a predetermined maximum velocity, and maintain the minimum following distance if there is a vehicle in front of the autonomous vehicle 105. The predetermined distance can include, for example, 200 m, 225 m, 250 m, 275 m and the predetermined maximum velocity can include, for example, 15 MPH, 20 MPH, 25 MPH, although other values are also possible without departing from aspects of this disclosure.

In response to detecting that the ramp meter light is red, the in-vehicle control computer 150 can be configured to stop the autonomous vehicle 105 no further than a predetermined first distance from the light line or no further than a predetermined second distance behind a front vehicle. The predetermined first distance can include, for example, 3 meters, 4 meters, 5 meters and the predetermined second distance can include, for example, 1 meter, 2 meters, 3 meters, although other distances are also possible. FIG. 9BJ illustrates an example visualization of traffic stopped at a ramp meter.

The in-vehicle control computer 150 can be configured to control the autonomous vehicle 105 to proceed through the ramp beyond the light line in response to determining that the light is green and the autonomous vehicle 105 is included in the number of allowed vehicles given by the flow control scheme in the autonomous vehicle’s 105 lane. For example, if the flow control scheme mentions 1 vehicle per green, the autonomous vehicle 105 is allowed to proceed through the ramp only if it was the first vehicle at the ramp light signal.

In response to detecting another entity (e.g., a vehicle) while approaching the ramp meter lights, the in-vehicle control computer 150 can further be configured to plan to control the autonomous vehicle 105 to come to a complete stop a predetermined distance away from the entity. The predetermined distance can include, for example, 3 m, 4 m, 5 m, although other values are also possible.

In response to detecting a crosswalk, the in-vehicle control computer 150 can be configured to control the autonomous vehicle 105 to stop where the autonomous vehicle’s 105 front most point is no further than a predetermined distance from the crosswalk line. The predetermined distance can include, for example, 3 m, 4 m, 5 m, although other distances are also possible.

After crossing the ramp meter lights and entering into the ramp which leads to the roadway, the in-vehicle control computer 150 can be configured to adjust the speed of the autonomous vehicle 105 in the ramp meter lane so that the autonomous vehicle 105 can find sufficient lateral width free to merge into a freeway lane. Getting the lateral sides of the autonomous vehicle 105 free permits the autonomous vehicle 105 to find a gap for merging in the requested lane and yielding to other vehicles whose bumper is ahead of the autonomous vehicle 105.

The in-vehicle control computer 150 can be configured to follow traffic using a zipper merge method in case of multiple lanes of the ramp merge into freeway lanes. After passing the ramp meter lights, the in-vehicle control computer 150 can be configured to yield to vehicles in other lanes, if the front most point of that vehicle is ahead of the autonomous vehicle 105. After that, the in-vehicle control computer 150 can be configured to control the autonomous vehicle 105 to move forward to merge into the lane.

When the autonomous vehicle 105 is driving on a freeway and the in-vehicle control computer 150 detects roadway vehicles merging in the autonomous vehicle’s 105 lane, the in-vehicle control computer 150 can be configured to control the autonomous vehicle 105 to follow merge rules. FIG. 9BK illustrates an example visualization of merging traffic.

Bumps

Another type of physical infrastructure that the in-vehicle control computer 150 can be configured to detect is bumps. As described herein, the in-vehicle control computer 150 may store a map within the memory 175 that includes a map of the roadways and nearby environment (see the Map Taxonomy section of this application). The map can include information regarding speed bumps, their type (e.g., speed hump, speed cushion, or speed table), and the distance between each bump. FIG. 9BL illustrates an example visualization of a speed bump.

As used herein, a speed bump may generally refer to a traffic calming device that uses vertical deflection to slow motor-vehicle traffic in order to improve safety conditions. Speed bumps can include, for example, speed humps, speed cushions, and speed tables.

As used herein, a speed hump may generally refer to a device which creates a gentle rocking sensation in a vehicle passing over the speed hump at the posted speed limit. If a vehicle is driving at unsafe speed, the hump will jar the vehicle and its contents, causing discomfort to the occupants and disruption to cargo. FIG. 9BM-9BO illustrate example visualizations of speed humps.

As used herein, a speed cushion may generally refer to a speed hump that includes wheel cutouts to allow large vehicles to pass unaffected, while reducing passenger vehicle speeds. They can be offset to allow unimpeded passage by emergency vehicles and are typically used on key emergency response routes. FIG. 9BP illustrates an example visualization of a speed cushion.

As used herein, a speed table may generally refer to a very long and broad speed hump, or for a flat-topped speed hump, where sometimes a pedestrian crossing is provided in the flat portion of the speed table. FIG. 9BQ illustrates an example visualization of a speed table.

The in-vehicle control computer 150 can be configured to detect traffic signs or pavement markings indicating the presence of speed bumps at a predetermined minimum distance. The predetermined minimum distance can include, for example, 200 m, 222 m, 250 m, 275 m, although other values are also possible.

The in-vehicle control computer 150 can be configured to detect if a speed bump is a temporary or permanent speed bump. For example, the in-vehicle control computer 150 can be configured to consider a portable bump as a temporary speed bump and an asphalt bump as a permanent speed bump. FIG. 9BR illustrates an example visualization of a portable speed bump.

The in-vehicle control computer 150 can be configured to determine if there is a conflict between the mapped and perceived speed bump information. In response, the in-vehicle control computer 150 can be configured to inform the oversight system 350 and prioritize the perceived information.

The in-vehicle control computer 150 can also be configured to inform the oversight system 350 in case of a not mapped permanent speed bump or in case of non-detected mapped permanent speed bump. FIG. 9BS illustrates an example visualization of a sign indicating the presence of a speed hump.

The in-vehicle control computer 150 can further be configured to detect traffic signs indicating the presence of speed bumps and determine the type of speed bump as the autonomous vehicle 105 approaches the start of the speed bump.

In some embodiments, the in-vehicle control computer 150 can be configured to approach a detected speed bump with a predetermined maximum speed and start accelerating to the level of allowed speed limit when rear most point of the autonomous vehicle 105 crosses the last speed bump. The predetermined maximum speed can include, for example, 4 mph, 5 mph, 6 mph, 8 mph, although other values are also possible.

The in-vehicle control computer 150 can also be configured to detect a speed limit traffic sign after the autonomous vehicle 105 crosses a speed bump to increase the speed as appropriate. FIG. 9BT illustrates an example visualization of a speed bump and a sign indicating a speed limit for the speed bump.

The in-vehicle control computer 150 can also be configured to detect whether a pedestrian is crossing the road using a cross walk area between ends of a speed table when the autonomous vehicle 105 is approaching the speed table at a predetermined minimum distance. The predetermined minimum distance can include, for example, 200 m, 222 m, 250 m, 275 m, although other distances are also possible.

The in-vehicle control computer 150 can also be configured to control the autonomous vehicle 105 to cross a speed table bump at a maximum speed and stop the autonomous vehicle 105 in response to detecting a pedestrian. The maximum speed can include, for example, 5 mph, although other speeds are also possible. FIG. 9BU illustrates an example visualization of a speed table with a cross walk.

As used herein, a pothole may generally refer to a depression in a road surface, usually asphalt pavement, where traffic has removed broken pieces of the pavement. Pothole may usually result from water in the underlying soil structure and traffic passing over the affected area. FIG. 9BV illustrates an example visualization of a pothole.

The in-vehicle control computer 150 can also be configured to detect the presence of a pothole and detect the location of the pothole (e.g., including the distance from the autonomous vehicle 105 to the pothole), as well as the width and depth of the pothole at a predetermined minimum distance. The predetermined minimum distance can include, for example, 200 m, 222 m, 250 m, 275 m, although other values are also possible.

In some embodiments, the in-vehicle control computer 150 can be configured to determine that a pothole is an avoidable pothole in response to the detected pothole having a width less than that of the autonomous vehicle’s 105 tire width and a depth less than a predetermined percentage of the autonomous vehicle’s 105 wheel diameter. The predetermined percentage can include, for example, 4%, 5%, 6%, although other values are also possible.

The in-vehicle control computer 150 can be configured to determine that a pothole is an avoidable pothole when the autonomous vehicle 105 can go around the pothole using lane bias.

The in-vehicle control computer 150 can also be configured to determine that a pothole is an unavoidable pothole in response to the pothole covering more than a predetermined amount of the lateral width of the lane and lane bias cannot be used to avoid the pothole. The predetermined amount can include, for example, 25%, 30%, 35%, although other values are also possible.

In response to detecting an unavoidable pothole having a width less than the autonomous vehicle’s 105 tire width and a depth less than the threshold percentage of the autonomous vehicle’s 105 wheel diameter, the in-vehicle control computer 150 can be configured to slow the autonomous vehicle 105 down to a predetermined amount of the current speed limit and plan to go over them. The predetermined amount can include, for example, 8%, 10%, 12%, although other values are also possible.

In response to detecting an avoidable pothole, the in-vehicle control computer 150 can be configured to slow the autonomous vehicle 105 down to a predetermined threshold percentage of the current speed limit and perform lane bias. The predetermined amount can include, for example, 8%, 10%, 12%, although other values are also possible.

In response to detecting a pothole in lane which is bigger than the autonomous vehicle’s 105 tire width and has a depth greater than a threshold percentage (e.g., 8%, 10%, 12%) of the autonomous vehicle’s 105 wheel diameter that can potentially cause damage, the in-vehicle control computer 150 can be configured to perform a critical lane change to ensures that the autonomous vehicle’s 105 wheels do not hit the detected pothole. The predetermined percentage can include, for example, 8%, 10%, 12%, although other values are also possible. In the case that the in-vehicle control computer 150 determines that a lane change is not possible, the in-vehicle control computer 150 can be configured to plan to stop the autonomous vehicle 105 a predetermined distance ahead of the potentially damaging pothole and inform the oversight system 350. The predetermined distance can include, for example, 4 meters, although other values are also possible.

Emergency Lanes

Still another type of physical infrastructure that the in-vehicle control computer 150 can be configured to detect is an emergency lane. Emergency lanes may be useful when the autonomous vehicle 105 needs to execute a first MRC maneuver. Emergency lanes may be a type of safe zone in which the autonomous vehicle 105 can complete an MRC maneuver.

The in-vehicle control computer 150 can be configured to identify situations related to the first MRC maneuver. As described herein, the first MRC maneuver can involve pulling the autonomous vehicle 105 onto a shoulder to safely stop.

As used herein, a road shoulder may generally refer to a strip of land immediately adjacent to the traffic lane of a road not bordered by curb and channel. FIG. 9BW illustrates an example visualization of a roadway with shoulders.

As used herein, a highway shoulder may generally refer to a right most or left most lane of a highway that is not operational or without traffic.

When travelling on a highway, the in-vehicle control computer 150 can be configured to determine that a shoulder is a permanent shoulder or a part time shoulder (outside of the shoulder’s access hours) having a width that is more than a predetermined number of times of the autonomous vehicle’s 105 width as an available shoulder for stop. The predetermined number of times can include, for example, 1.1 times, 1.2 times, 1.25 times, 1.3 times, although other values are also possible. FIG. 9BX illustrates an example visualization of a highway with a shoulder.

When travelling on a local road, the in-vehicle control computer 150 can be configured to consider a shoulder having width greater than a predetermined number of times of the autonomous vehicle’s 105 width as an available shoulder. The predetermined number of times can include, for example, 1.1 times, 1.2 times, 1.25 times, 1.3 times, although other values are also possible.

The in-vehicle control computer 150 may store a map within the memory 175 that includes a map of the roadways and nearby environment (see the Map Taxonomy section of this application). The map can include information regarding the nearest available shoulder for stopping the autonomous vehicle 105.

The in-vehicle control computer 150 can be configured to detect the nearest available shoulder for stopping at a predetermined distance. The predetermined distance can include, for example, 200 m, 222 m, 250 m, 275 m, although other values are also possible.

The in-vehicle control computer 150 can be configured to estimate the entry point where the autonomous vehicle 105 can start entering into the shoulder.

In some embodiments, the in-vehicle control computer 150 can be configured to estimate the speed at which the autonomous vehicle 105 may enter into the shoulder and plan to stop the autonomous vehicle 105 when the lane change is complete.

The in-vehicle control computer 150 can be configured to detect any obstacle like barricades, marker cone, or barriers in the available shoulder at a predetermined distance. The predetermined distance can include, for example, 200 m, 222 m, 250 m, 275 m, although other values are also possible.

The in-vehicle control computer 150 can be configured to estimate the remaining length of the available shoulder in case any barricade or vehicle is present in the shoulder before the autonomous vehicle 105 enters into the shoulder to pull over.

The in-vehicle control computer 150 can be configured to detect the shoulder composition (e.g., asphalt, concrete, mixed, grating, scraped road, potholes) at a predetermined distance. The predetermined distance can include, for example, 200 m, 222 m, 250 m, 275 m, although other values are also possible.

In some embodiments, the in-vehicle control computer 150 can be configured to estimate the coefficient of friction of the shoulder based on the detected shoulder composition. The in-vehicle control computer 150 can also be configured to estimate the braking distance required on the upcoming available shoulder considering the target speed at which the autonomous vehicle 105 will approach the shoulder. In some embodiments, the in-vehicle control computer 150 can be configured to enter the shoulder in response to determining that the available length of the shoulder is greater than a braking distance of the autonomous vehicle 105 plus a length of the autonomous vehicle 105 plus a predetermined margin distance. The predetermined margin distance can include, for example, 1.5 m, 2 m, 2.5 m, 3 m, although other values are also possible.

Roadway Width

Still yet another type of physical infrastructure that the in-vehicle control computer 150 can be configured to detect is the width of the roadway. As used herein, the road width may generally refer to the dimension of the roadway width up to a predetermined distance. The predetermined distance can include, for example, 40 m, 45 m, 48.96 m, 50 m, 55 m, although other values are also possible. There may be four main road types that the autonomous vehicle 105 may encounter: state highway (two-lane road for each direction); national highway; district road; rural roads or village roads. FIG. 9BY-9CA illustrate example visualizations of roadways having different widths.

As used herein, a road segment may generally refer to a piece of the roadway. For example, road segments can include parts of curved road segments, superelevation road segments, or straight roads.

As used herein, a road lane may generally refer to a road segment where the size of the road lane multiplied by the total number of lanes gives the road width.

The in-vehicle control computer 150 may store a map within the memory 175 that includes a map of the roadways and nearby environment (see the Map Taxonomy section of this application). The map can include information including metadata regarding road segments with the road lane width. The lane width may be defined such that it does not change on the same road. The map can also include metadata on road segments with the number of lanes.

The in-vehicle control computer 150 can be configured to detect roadways with different width, and in response, the in-vehicle control computer 150 can be configured to adapt the motion planning of the autonomous vehicle 105 with help of the onboard perception system (e.g., the vehicle sensor subsystems 144) to drive on an estimated right lane of the road. Lane width may have an impact on motion planning since the autonomous vehicle 105 may have less margin for error on narrower lanes.

The in-vehicle control computer 150 can also be configured to plan an alternate route in response to determining that the autonomous vehicle 105 has come across a road with a width greater than a predetermined distance. The predetermined distance can include, for example, 40 m, 45 m, 48.96 m, 50 m, 55 m, although other distances are also possible.

The in-vehicle control computer 150 can be configured to position the autonomous vehicle 105 on the center of the lane (e.g., the road lane width divided by 2 from the outer edge of the road).

The in-vehicle control computer 150 can be configured to prefer driving the autonomous vehicle 105 in the right most lane for its mission unless the in-vehicle control computer 150 can be configured to determines that a lane change lane can be used for passing around slow moving or stationary vehicles/entities. In some situations, when the autonomous vehicle 105 is embodied as a truck, it may have to drive on the most-right lane due to speed limits (some lanes have a minimum speed) and overtake constraints. FIG. 9CB-9CD illustrate example visualizations of signs that indicate whether trucks are permitted in a given lane or roadway.

The in-vehicle control computer 150 can be configured to control the autonomous vehicle 105 to overtake a slow moving vehicle in front if a do not pass sign is not detected for the corresponding stretch of the road and the left-hand side lane width allows the autonomous vehicle 105 to perform the maneuver.

In some embodiments, the in-vehicle control computer 150 can be configured to prefer roads with lane markings. For example, there are roads where markings are not visible or eroded with weather. The in-vehicle control computer 150 can be configured to plan to drive on roads with reliable markings, for example, as reflected in the map.

In response to determining that markings are not present or visible, the in-vehicle control computer 150 can be configured to derive the central position of the road and find or establish virtual markings. There are roads where markings are not visible or eroded with weather. The in-vehicle control computer 150 can be configured to find the center of the road and derive the virtual lane marks.

In response to detecting extra wide lanes (e.g., lanes with a width greater than a predetermined width), the in-vehicle control computer 150 can be configured to adapt the motion planning with help of the onboard perception system to estimate the center of such extra wide lane and continue the autonomous vehicle’s 105 mission.

Tunnel Detection

Another type of physical infrastructure that the in-vehicle control computer 150 can be configured to detect are tunnels. It can be desirable to detect the presence of tunnels both to ensure that the autonomous vehicle 105 can safely traverse the vertical clearance of the tunnel as well as to plan for any loss of wireless data connection to the oversight system 350 while inside the tunnel.

As used herein, vertical clearance may generally refer to the minimum distance between the drivable pavement of the road and the lowest point of any object located above the drivable pavement. FIG. 9CE illustrates an example visualization of the vertical clearance of a tunnel.

As used herein, low vertical clearance may generally refer to the vertical distance lower than the maximum height of the trailer or truck height of the autonomous vehicle 105 with addition of a predetermined distance. The predetermined distance can include, for example, 0.25 m, 0.5 m, 0.75 m, although other values are also possible.

The in-vehicle control computer 150 may store a map within the memory 175 that includes a map of the roadways and nearby environment (see the Map Taxonomy section of this application). The map can include information regarding signs that indicate the presence of a tunnel as well as the location of the tunnel. The map can be periodically (e.g., continuously in some embodiments) updated to include closed tunnel locations. The map can also include the availability of GPS reception and its function based on historical observation for tunnels in the map.

The in-vehicle control computer 150 can be configured to detect the presence of a tunnel from relevant traffic at a predetermined distance. The predetermined distance can include, for example, 200 m, 222 m, 250 m, although other distances are also possible. The in-vehicle control computer 150 can be configured to determine stopping distance as the distance necessary to stop with a predetermined deceleration. The predetermined deceleration can include, for example, 2.25 m/s2, 2.5 m/s2, 2.75 m/s2, although other values are also possible.

The in-vehicle control computer 150 can be configured to detect if a tunnel is closed from relevant traffic signs at a predetermined distance. The predetermined distance can include, for example, 200 m, 222 m, 250 m, although other values are also possible.

In some embodiments, the in-vehicle control computer 150 can be configured to detect the vertical clearance information for a tunnel from relevant traffic signs at a predetermined distance. The predetermined distance can include, for example, 200 m, 222 m, 250 m, although other values are also possible. FIG. 9CF-9CG illustrate example visualizations of a tunnel and signs that indicate the vertical clearance for the tunnel.

The in-vehicle control computer 150 can be configured to detect the requirement for usage of headlights from relevant illumination traffic signs at a predetermined distance. The predetermined distance can include, for example, 200 m, 222 m, 250 m, although other values are also possible. FIG. 9CH illustrates an example visualization of a sign indicating that headlights should be used in the upcoming tunnel.

In some embodiments, the in-vehicle control computer 150 can be configured to periodically (or continuously in some embodiments) monitor the vertical clearance on the planned path in front of the autonomous vehicle 105 with a distance greater than the distance necessary to stop the vehicle with a predetermined deceleration. The predetermined deceleration may include, for example, 2.25 m/s2, 2.5 m/s², 2.75 m/s2, although other values are also possible.

In response to determining that the autonomous vehicle 105 is inside a tunnel, the in-vehicle control computer 150 can be configured to determine if the autonomous vehicle’s 105 GPS receiver’s signal strength indicator (RSSI) is less than a threshold level. The threshold level can include, for example, 25%, 30%, 35%, although other values are also possible.

In some embodiments, the in-vehicle control computer 150 can be configured to plan a route such that all vertical clearances are higher than the low vertical clearance threshold value.

In response to detecting a tunnel on the autonomous vehicle’s 105 current path, the in-vehicle control computer 150 can be configured to slow the autonomous vehicle 105 down by a margin from the initial speed to give a more accurate measurement. The initial margin can include, for example, between 5 to 10 mph, although other values are also possible.

When the autonomous vehicle 105 is in a tunnel, the in-vehicle control computer 150 can be configured to avoid lane changes other than critical lane changes.

The in-vehicle control computer 150 can be configured to inform the oversight system 350 that the autonomous vehicle 105 will enter a tunnel a predetermined length of time before entering the tunnel. The predetermined length of time can include, for example, 8 s, 10 s, 12 s, 15 s, although other values are also possible. In particular, the in-vehicle control computer 150 can be configured to inform the yard operator that the autonomous vehicle 105 will enter the tunnel. The in-vehicle control computer 150 can also be configured to inform the oversight system 350 in response to the autonomous vehicle 105 exiting the tunnel. The in-vehicle control computer 150 can also be configured to inform the yard operator. If the oversight system 350 or the yard operator does not receive confirmation that the autonomous vehicle 105 has left the tunnel within a predetermined length of time, the oversight system 350 may send help to assist in case the autonomous vehicle 105 was unable to complete navigation through the tunnel.

The in-vehicle control computer 150 can be configured to turn on the autonomous vehicle’s 105 headlights in response to entering a tunnel.

In some embodiments, the in-vehicle control computer 150 can be configured to use an alternate form of localization if there is no GPS reception in the tunnel. For example, the in-vehicle control computer 150 can be configured to use on board sensors (e.g., cameras, Radar, and Lidar) for truck localization in the tunnel.

In response to determining that low vertical clearance is present on the autonomous vehicle’s 105 path, the in-vehicle control computer 150 can be configured to inform the oversight system 350 of the vertical clearance’s location and height.

In response to detecting a low vertical clearance is detected and determining that no alternate route is available, the in-vehicle control computer 150 can be configured to control the autonomous vehicle 105 to stop on a shoulder or emergency lane, or pull over to the rightmost lane no less than a predetermined distance away from the low vertical clearance and inform the oversight system 350. The predetermined distance can include, for example, 40 m, 45 m, 50 m, 55 m, 60 m, although other values are also possible. The in-vehicle control computer 150 can be configured to turn on the autonomous vehicle’s 105 hazard lights and/or trigger the first MRC maneuver.

In response to detecting a closed tunnel, the in-vehicle control computer 150 can be configured to control the autonomous vehicle 105 to stop on a shoulder or emergency lane, or pull over the rightmost lane, and inform the oversight system. The in-vehicle control computer 150 can be configured to turn on the autonomous vehicle’s hazard lights and/or trigger the first MRC maneuver.

In response to determining that a tunnel is closed due to an emergency situation and detecting the presence of emergency traffic control devices, the in-vehicle control computer 150 can be configured to stop on a shoulder or emergency lane, or pull over to the rightmost lane no less than a predetermined distance away from traffic control devices, and inform the oversight system 350. The predetermined distance can include, for example, 40 m, 45 m, 50 m, 55 m, 60 m, although other values are also possible. The in-vehicle control computer 150 can be configured to turn on the autonomous vehicle’s 105 hazard lights and/or trigger the first MRC maneuver.

When the autonomous vehicle 105 has stopped because of low vertical clearance and if no alternative route is available, the in-vehicle control computer 150 can be configured to inform the oversight system 350.

Example Technique for Controlling an Autonomous Vehicle During an MRC Maneuver

One objective of this disclosure includes controlling an autonomous vehicle 105 during an MRC maneuver. FIG. 9CI illustrates an example method which can be used to control the autonomous vehicle 105 during an MRC maneuver. The method 910 may be described herein as being performed by one or more processors, which may include the in-vehicle control computer 150.

The method 910 begins at block 911. At block 912, the in-vehicle control computer 150 is configured to determine a minimal risk condition (MRC) maneuver for the autonomous vehicle to execute. The MRC maneuver may include a first MRC maneuver in which the autonomous vehicle 105 pulls over to a safe zone on a shoulder of the roadway.

At block 914, the in-vehicle control computer 150 is configured to identify a safe zone in which the autonomous vehicle 105 is able to execute the MRC maneuver by coming to a stop based on perception data received from at least one perception sensor of the autonomous vehicle. The at least one perception sensor is configured to generate the perception data to be indicative of physical infrastructure (e.g., including the safe zone) on or near a roadway.

At block 916, the in-vehicle control computer 150 is configured to identify one or more exclusion zones within the safe zone based on the perception data. The exclusion zone may identify an area in which the autonomous vehicle 105 cannot enter during the MRC maneuver.

At block 918, the in-vehicle control computer 150 is configured to control the autonomous vehicle to execute the MRC maneuver including stopping outside of the exclusion zone. The method 910 ends at block 920.

Conclusion

All of the above reactive features and supporting features may present in an autonomous truck in a reasonable combination.

Though much of this document refers to an autonomous truck, it should be understood that any autonomous ground vehicle may have such features. Autonomous vehicles which traverse over the ground may include: semis, tractor-trailers, 18 wheelers, lorries, class 8 vehicles, passenger vehicles, transport vans, cargo vans, recreational vehicles, golf carts, transport carts, and the like.

While several embodiments have been provided in this disclosure, it should be understood that the disclosed systems and methods might be embodied in many other specific forms without departing from the spirit or scope of this disclosure. The present examples are to be considered as illustrative and not restrictive, and the intention is not to be limited to the details given herein. For example, the various elements or components may be combined or integrated in another system or certain features may be omitted, or not implemented.

In addition, techniques, systems, subsystems, and methods described and illustrated in the various embodiments as discrete or separate may be combined or integrated with other systems, modules, techniques, or methods without departing from the scope of this disclosure. Other items shown or discussed as coupled or directly coupled or communicating with each other may be indirectly coupled or communicating through some interface, device, or intermediate component whether electrically, mechanically, or otherwise. Other examples of changes, substitutions, and alterations are ascertainable by one skilled in the art and could be made without departing from the spirit and scope disclosed herein.

To aid the Patent Office, and any readers of any patent issued on this application in interpreting the claims appended hereto, applicants note that they do not intend any of the appended claims to invoke 35 U.S.C. § 112(f) as it exists on the date of filing hereof unless the words “means for” or “step for” are explicitly used in the particular claim. 

What is claimed is:
 1. An autonomous vehicle comprising: at least one perception sensor configured to generate perception data indicative of a condition of the environment; a network communication transceiver configured to communicate with an oversight system; a non-transitory computer readable medium; and a processor configured to: receive the perception data from the at least one perception sensor, receive an indication of the condition of the environment from the oversight system, determine an expected condition of the environment at a future time based on the perception data and the indication of the condition of the environment, predict a road traction level for the autonomous vehicle at the future time based on the expected condition of the environment, and navigate the autonomous vehicle based on the predicted road traction level.
 2. The autonomous vehicle of claim 1, wherein the processor is further configured to: receive an expected temperature of the environment at the future time from the oversight system, wherein the predicting of the road traction level for the autonomous vehicle at the future time is further based on the expected temperature of the environment.
 3. The autonomous vehicle of claim 2, wherein the predicting of the road traction level for the autonomous vehicle at the future time comprises: determining that there is a risk of low road traction at the future time in response to the expected temperature being less than a threshold temperature.
 4. The autonomous vehicle of claim 1, wherein the processor is further configured to: determine a road surface type based on a predetermined map stored in the non-transitory computer readable medium, wherein the predicting of the road traction level for the autonomous vehicle at the future time is further based on the determined road surface type.
 5. The autonomous vehicle of claim 4, wherein the determining of the road surface type is further based on the perception data.
 6. The autonomous vehicle of claim 1, wherein the processor is further configured to: detect understeering of the autonomous vehicle based on the perception data, and estimate a current road traction level for the autonomous vehicle based on the detected understeering of the autonomous vehicle.
 7. The autonomous vehicle of claim 1, wherein the processor is further configured to: detect a response of the autonomous vehicle to a command to accelerate the autonomous vehicle, and estimate a current road traction level for the autonomous vehicle based on the detected response of the autonomous vehicle to the command to accelerate the autonomous vehicle.
 8. The autonomous vehicle of claim 1, wherein the processor is further configured to: detect a response of the autonomous vehicle to a command to apply a torque to one or more wheels of the autonomous vehicle, and estimate a current road traction level for the autonomous vehicle based on the detected response of the autonomous vehicle to a command to apply the torque to the one or more wheels of the autonomous vehicle.
 9. The autonomous vehicle of claim 8, wherein: the detecting the response of the autonomous vehicle to the command to apply the torque to the one or more wheels of the autonomous vehicle comprises determining a slip rate from tires of the autonomous vehicle in response to the command to apply the torque to the one or more wheels, and the estimating the current road traction level for the autonomous vehicle is further based on the determined slip rate from the tires of the autonomous vehicle.
 10. The autonomous vehicle of claim 1, wherein the processor is further configured to: determine that the predicted road traction level is less than a predetermined road traction level, and in response to determining that the predicted road traction level is less than the predetermined road traction level, limit lateral acceleration of the autonomous vehicle to a threshold lateral acceleration value.
 11. The autonomous vehicle of claim 10, wherein the processor is further configured to: in response to determining that the predicted road traction level is less than the predetermined road traction level, limit jerk of the autonomous vehicle to a threshold jerk value.
 12. A non-transitory computer-readable medium having stored thereon instructions which, when executed by a processor, cause the processor to: receive perception data from at least one perception sensor of an autonomous vehicle, the at least one perception sensor configured to generate perception data indicative of a condition of the environment; receive an indication of the condition of the environment from an oversight system via a network communication transceiver of the autonomous vehicle; determine an expected condition of the environment at a future time based on the perception data and the indication of the condition of the environment; predict a road traction level for the autonomous vehicle at the future time based on the expected condition of the environment; and navigate the autonomous vehicle based on the predicted road traction level.
 13. The non-transitory computer-readable medium of claim 12, wherein the instructions further cause the processor to: dynamically adjust a following distance from other vehicles directly ahead of the autonomous vehicle based at least in part on the predicted road traction level and a safe longitudinal deceleration required to completely stop the autonomous vehicle.
 14. The non-transitory computer-readable medium of claim 13, wherein the instructions further cause the processor to: determine the safe longitudinal deceleration required to completely stop the autonomous vehicle based on a road surface type and the predicted road traction level.
 15. The non-transitory computer-readable medium of claim 13, wherein the dynamically adjusting the following distance instructions comprise: determining the following distance to be greater than the safe longitudinal deceleration required to completely stop the autonomous vehicle.
 16. The non-transitory computer-readable medium of claim 12, wherein the instructions further cause the processor to: determine that the predicted road traction level is less than a threshold road traction level, and in response to determining that the predicted road traction level is less than the threshold road traction level, cause the autonomous vehicle to execute a minimal risk condition (MRC) maneuver.
 17. The non-transitory computer-readable medium of claim 16, wherein the MRC maneuver comprises pulling the autonomous vehicle over to a safe zone of a roadway.
 18. A method, comprising: receiving perception data from at least one perception sensor of an autonomous vehicle, the at least one perception sensor configured to generate perception data indicative of a condition of the environment; receiving an indication of the condition of the environment from an oversight system via a network communication transceiver of the autonomous vehicle; determining an expected condition of the environment at a future time based on the perception data and the indication of the condition of the environment; predicting a road traction level for the autonomous vehicle at the future time based on the expected condition of the environment; and navigating the autonomous vehicle based on the predicted road traction level.
 19. The method of claim 18, further comprising: determining that the autonomous vehicle will operate out of an operational design domain (ODD) of the autonomous vehicle at the future time based on the predicted road traction level, and in response to determining that the autonomous vehicle will operating out of the ODD, causing the autonomous vehicle to execute a first minimum risk condition (MRC) maneuver.
 20. The method of claim 19, further comprising: determining that the autonomous vehicle has been attempting the first MRC for longer than a predetermined period of time without success, and in response to determining that the autonomous vehicle has been attempting the first MRC for longer than a predetermined period of time without success, causing the autonomous vehicle to execute a second MRC maneuver. 